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Foreword 



This ETSI Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This TS defines the logical link control layer protocol to be used for packet data transfer between the Mobile Station 
(MS) and Serving GPRS Support Node (SGSN) within the digital cellular telecommunications system. 

The contents of this TS is subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS, it will be re-released by SMG with an identifying change of release date 
and an increase in version number as follows: 

Version 6.x.y 

where: 

6 indicates GSM Phase 2+ Release 1997; 

x the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc.; 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 



This specification defines the Logical Link Control (LLC) layer protocol to be used for packet data transfer between the 
Mobile Station (MS) and Serving GPRS Support Node (SGSN). 

It defines the frame structure, elements of procedure, format of fields, and procedures for the proper operation of the 
logical link control layer. It is based on ideas contained in IS-130 [21], ISO 3309 [16], ISO 4335 [17], and 
ISO 7809 [18, 19, 20] (HDLC of ISO), as well ITU-T Q.920 [13] and Q.921 [14] (LAPD). The concepts, the overview 
description of LLC layer functions and procedures, and the relationship with other Technical Specifications are 
described in general terms in GSM 03.60 [5]. 

LLC spans from the Mobile Station (MS) to the Serving GPRS Support Node (SGSN). LLC is intended for use with 
both acknowledged and unacknowledged data transfer. 

The frame formats defined for LLC are based on those defined for LAPD and RLP. However, there are important 
differences between LLC and other protocols, in particular with regard to frame delimitation methods and transparency 
mechanisms. These differences are necessary for independence from the radio path. 

The LLC procedures are modelled upon the concepts of HDLC as outlined in ISO 4335. Data sequence integrity 
between the data source and data sink is effected by means of a cyclic numbering scheme. An independent numbering 
scheme is used for each logical data link, as identified by the a data link connection identifier. LLC supports two modes 
of operation: 

Unacknowledged peer-to-peer operation: 

A logical link entity may initiate transmissions to a peer entity without prior establishment of a logical connection 
with the peer entity. LLC does not guarantee in-order delivery. LLC can detect errors in a received frame, and, 
depending on whether the frame is sent in protected mode or not, either discard or deliver the erroneous frame. 
No error recovery procedures are defined at the LLC layer. Higher-layer protocols can be used to provide 
reliability, if needed. This mode of operation is known as Asynchronous Disconnected Mode (ADM). 

Acknowledged peer-to-peer operation: 

A balanced data link involves two participating entities, and each entity assumes responsibility for the 
organisation of its data flow and for error recovery procedures associated with the transmissions that it originates. 
Each entity operates as both a data source and data sink in a balanced link, allowing information to flow in both 
directions. This mode of operation is known as Asynchronous Balanced Mode (ABM), and provides a reliable 
service with in-order delivery. 

This specification is organised as follows: 

An overview of the LLC layer functions is given in clause 4. 

The frame structure for peer-to-peer communication is given in clause 5. 

The elements of procedure and formats of fields are given in clause 6. 

The elements of layer-to-layer communication are contained in clause 7. 

The details of the peer-to-peer ABM procedures are given in clause 8. 

The details of LLC frame ciphering are given in annex A. 

An overview of the LLC layer states is provided in annex B. 



2 Normative references 

References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 
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b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 



[1] GSM 01.04: "Digital cellular telecommunications system (Phase 2+) 

acronyms". 

[2] GSM 01.61: "Digital cellular telecommunications system (Phase 2+) 

requirements". 

[3] GSM 02.60: "Digital cellular telecommunications system (Phase 2+) 

Service (GPRS); Service description; Stage 1". 

[4] GSM 03.40: "Digital cellular telecommunications system (Phase 2+) 

Short Message Service (SMS); Point-to-Point (PP)". 

[5] GSM 03.60: "Digital cellular telecommunications system (Phase 2+) 

Service (GPRS); Service description; Stage 2". 

[6] GSM 03.64: "Digital cellular telecommunications system (Phase 2+) 

General Packet Radio Service (GPRS) Radio interface; Stage 2". 

[7] GSM 04.01: "Digital cellular telecommunications system (Phase 2+) 

Station System (MS - BSS) interface; General aspects and principles 

[8] GSM 04.08: "Digital cellular telecommunications system (Phase 2+) 

3 specification". 



Abbreviations and 
GPRS ciphering algorithm 
General Packet Radio 
Technical realization of the 
General Packet Radio 
Overall description of the 
Mobile Station - Base 
Mobile radio interface layer 



[9] GSM 04.1 1: "Digital cellular telecommunication system (Phase 2+); Point-to-Point (PP) Short 

Message Service (SMS) support on mobile radio interface". 

[10] GSM 04.22: "Digital cellular telecommunications system (Phase 2+); Radio Link Protocol (RLP) 

for data and telematic services on the Mobile Station - Base Station System (MS - BSS) interface 
and the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface". 

[11] GSM 04.65: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Subnetwork Dependent Convergence Protocol (SNDCP)". 

[12] GSM 08.18: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS 
Protocol (BSSGP)". 

[13] ITU-T Q.920 (1988): "ISDN user-network interface data link layer - general aspects". 

[14] ITU-T Q.921 (1988): "ISDN user-network interface - data link layer specification". 

[15] ITU-T Z.100 (1988): "CCITT specification and description language (SDL)". 

[16] ISO 3309 (1984): "Information processing systems - Data communications - High-level logical 

link control procedures - Frame structure". 

[17] ISO 4335 (1987): "Information processing systems - Data communication - High-level logical link 

control procedures - Consolidation of elements of procedures". 

[18] ISO 7809 (1984): "Information processing systems - Data communication - High-level logical link 

control procedures - Consolidation of classes of procedures". 
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[19] ISO 7809 (1984): "Information processing systems - Data communication Add. 1: 1987 - High- 

level logical link control procedures - Consolidation of classes of procedures - Addendum 1 ". 

[20] ISO 7809 (1984): "Information processing systems - Data communication Add. 2: 1987 - High- 

level logical link control procedures - Consolidation of classes of procedures - Addendum 2: 
Description of optional functions". 

[21] TIA IS-130 (1995): "800 MHz Cellular System - TDMA Radio Interface - Radio Link Protocol 1" 

Arlington: Telecommunications Industry Association. 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of this specification the following definitions apply. Additional applicable definitions can be found in 
GSM 02.60 [3]. 

frame rejection condition: a condition that results from the receipt of an undefined or incorrect frame. 

inquiry process: a process performed in the peer receiver busy condition in which the LLE checks that the peer LLE is 
still in the own receiver busy condition. 

invalid frame condition: a condition that results from the receipt of an invalid frame. 

logical link connection: the logical connection between two LLE peers. A logical link connection is identified with a 
Data Link Connection Identifier (DLCI). A logical link connection is always in one of three states: TLLI Unassigned, 
TLLI Assigned / ADM, or ABM. 

logical link control layer: the protocol layer between an MS and an SGSN consisting of one or more logical link 
management entities, one or more logical link entities, and a multiplex procedure. 

logical link entity: the LLC layer protocol state machine controlling one logical link connection. 

own receiver busy condition: a condition that results from the inability to accept additional I frames from the peer 
logical link entity. 

peer receiver busy condition: a condition that results from the reception in of a RNR frame from the peer logical link 
entity. 

3.2 Abbreviations 

For the purposes of this specification the following abbreviations apply. Additional applicable abbreviations and 
symbols can be found in GSM 01.04 [1] and GSM 03.60. 

ABM Asynchronous Balanced Mode 

ACK ACKnowledgement 

ADM Asynchronous Disconnected Mode 

CNF Confirm 

DISC Disconnect 

DM Disconnected Mode 

FRMR FRaMe Reject 

GMM GPRS Mobility Management 

GRR GPRS Radio Resources service access point 

I Information 

IOV Input Offset Value 

IND Indication 

LAPD Link Access Procedure on the D-channel 

LL Logical Link 

LLC Logical Link Control 
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LLE Logical Link Entity 

LLGMM LLC to GPRS Mobility Management service access point 

LLM Logical Link Management 

LLME Logical Link Management Entity 

REQ Request 

RES Response 

RNR Receive Not Ready 

RR Receive Ready 

S Supervisory 

SABM Set Asynchronous Balanced Mode 

SACK Selective ACKnowledgement 

TIA Telecommunications Industry Association 

UA Unnumbered Acknowledgement 

UI Unconfirmed Information 

XID eXchange IDentification 



4 Overview description of LLC functions and 

procedures 

The requirements of the LLC layer can be summarised as follows: 

LLC shall provide a highly reliable logical link between the MS and the SGSN. 

LLC shall be independent of the underlying radio interface protocols in order to allow introduction of alternative 
GPRS radio solutions with minimal change to the NSS. 

LLC shall support variable-length information frames. 

LLC shall support peer-to-peer data transfers. 

LLC shall support both acknowledged and unacknowledged data transfers. 

LLC shall permit information transfer between the SGSN and one or more MSs using the same physical (e.g., 
radio) resources. Thus each LLC frame shall uniquely identify the MS sending (uplink) or receiving (downlink) 
the information. 

LLC shall allow information transfer with different service criteria, such that high-priority data transfers may take 
precedence over lower-priority transfers to the same MS. 

LLC shall provide user data confidentiality by means of a ciphering function. 

LLC shall support user identity confidentiality. 
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4.1 



Reference model 



A model of layering the protocols in GPRS is illustrated in Figure 1 . 
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Figure 1 : Protocol layering in GPRS 

The LLC layer operates above the RLC and BSSGP layers in the reference architecture to provide logical links between 
an MS and its SGSN. 

Above the LLC layer is located the SubNetwork Dependent Convergence (SNDC) layer, that controls the transfer of 
user data network layer PDUs (N-PDUs) between the MS and SGSN. The SNDC functionality is described in 
GSM 03.60 and specified in GSM 04.65 [11]. 

The logical link control layer Service Access Points (SAPs) are the points at which the LLC layer provides services to 
the layer-3 protocols in Figure 1 . In addition to the SNDC protocol, LLC provides service to the GPRS Mobility 
Management (GMM) protocol, and to the SMS protocol. 

An LLC layer connection is identified by the DLCI consisting of the SAP Identifier (SAPI) and the MS's Temporary 
Logical Link Identifier (TLLI). 

Each LLC frame consists of the header, trailer, and information field. The header and trailer fields contain information 
such as SAPI, frame number and checksum, that are used to identify the frame and to provide reliable transmission. The 
information field is variable length. Both transmission and retransmission of each frame are controlled by the LLC layer. 

Many of the formats and procedures are similar to the reference protocols, and differences are introduced only where 
needed to reflect the unique aspects of the GPRS architecture and requirements. 

4.2 General description of the LLC protocol 

LLC is considered to be a sublayer of layer 2 in the ISO 7-layer model. The purpose of LLC is to convey information 
between layer-3 entities in the MS and SGSN. Specifically, LLC shall support: 

multiple MSs at the Um interface; 

multiple layer-3 entities within an MS. 

LLC includes functions for: 

the provision of one or more logical link connections discriminated between by means of a DLCI; 

sequence control, to maintain the sequential order of frames across a logical link connection; 

detection of transmission, format and operational errors on a logical link connection; 

- recovery from detected transmission, format, and operational errors; 

notification of unrecoverable errors; 
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flow control; and 

ciphering. 

LLC layer functions provide the means for information transfer via peer-to-peer logical link connections between an MS 
and SGSN pair. 

4.2.1 Services required by the lower layers 

LLC requires the following services from the layers below: 

- LLC PDU delimitation to allow the LLC layer to determine the first octet and the last octet in each LLC PDU; 
and 

- transport of the MS address (a TLLI) of each LLC PDU between the MS and the SGSN. 



4.3 Unacknowledged operation 



With this type of operation, layer-3 information is transmitted in numbered Unconfirmed Information (UI) frames. The 
UI frames are not acknowledged at the LLC layer. Neither error recovery nor reordering mechanisms are defined, but 
transmission and format errors are detected. Duplicate UI frames are discarded. 

Flow control procedures are not defined. 

Two modes of unacknowledged operation are defined: 

- protected mode in which the FCS field protects the frame header and information field; and 

unprotected mode in which the FCS field protects the frame header but not the information field. 

Unacknowledged operation is allowed for all non-reserved SAPIs (see Table 2). 



4.4 Acknowledged operation 



With this type of operation, layer-3 information is transmitted in order in numbered Information (I) frames. The I frames 
are acknowledged at the LLC layer. Error recovery and reordering procedures based on retransmission of 
unacknowledged I frames are specified. Several I frames may be unacknowledged at the same time. In the case of errors 
that cannot be corrected by the logical link control layer, a report to GPRS mobility management shall be made. 

Flow control procedures are defined. 

Acknowledged operation requires that ABM operation has been initiated by an establishment procedure using the Set 
Asynchronous Balanced Mode (SABM) command. 

Acknowledged operation is not allowed for SAPIs 1 and 7. 

4.5 Establishment of information transfer modes 
4.5.1 Data link connection identification 

A logical link connection is identified by a DLCI consisting of two identifiers: a SAPI and a TLLI. 

The SAPI is used to identify the service access point on the SGSN side and the MS side of the LLC interface. SAPI is 
carried in the address field of each LLC frame. 

The TLLI is used to identify a specific MS. TLLI assignment is controlled by GMM. TLLI is not carried in LLC frames, 
but in BSSGP messages as defined in GSM 08.18 [12], and in RLC/MAC blocks as defined in GSM 04.08 [8]. 
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4.5.2 Logical link states 

A logical link entity may be in one of three basic states: 

TLLI Unassigned state: unacknowledged information transfer shall be possible in the MS-to-SGSN direction for 
SAPI=1; 

TLLI Assigned / ADM state: in this state a TLLI has been assigned. Unacknowledged information transfer shall 
be possible; or 

ABM state: this state shall be established by means of an ABM establishment procedure. Both acknowledged and 
unacknowledged information transfer shall be possible. 

The basic states and additional states are shown in annex B. 

4.5.3 TLLI assignment 

TLLI assignment is controlled by GMM. TLLIs are assigned, changed, and unassigned with the LLGMM-ASSIGN- 
REQ primitive, as described in subclause 7.2.1.1. 

4.5.4 Establishment of ABM operation 

Before peer-to-peer acknowledged information transfer can start, an exchange of a SABM frame and an Unnumbered 
Acknowledgement (UA) frame shall take place. The ABM establishment procedure is specified in clause 8. 

4.6 Data confidentiality 

The LLC layer shall provide data confidentiality by ciphering the information and FCS fields of data frames: 

The information and FCS fields of I frames shall be ciphered whenever ciphering information has been assigned 
to the associated TLLI. 

The information and FCS fields of UI frames shall be ciphered whenever layer 3 indicates that the UI frame shall 
be ciphered and ciphering information has been assigned to the associated TLLI. 
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4.7 LLC layer structure 



The LLC layer structure is shown in Figure 2. This figure is a model shown for illustrative purposes only, and does not 
constrain implementations. 
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Figure 2: Functional model of the LLC layer 



4.7.1 Logical Link Entity 



The logical link procedures consist of multiple Logical Link Entities (LLEs) that control the information flow of 
individual connections. There may be multiple LLEs per TLLI. Functions provided by each LLE are: 

unacknowledged information transfer; 

acknowledged information transfer; 

flow control in ABM operation; and 

frame error detection. 

The LLE analyses the control field of the received frame (see subclause 6.3) and provides appropriate responses and 
layer-to-layer indications. In addition, LLE analyses the LLC layer service primitives and transmits the appropriate 
command and response frames. There is one logical link entity for each DLCI. 
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4.7.2 Multiplex procedure 



On frame transmission, the multiplex procedure generates and inserts the FCS, performs the frame ciphering function, 
and provides SAPI-based logical link control layer contention resolution between the various LLEs. 

On frame reception, the multiplex procedure performs the frame decipher function and checks the FCS . If the frame 
passes the FCS check, the multiplex procedure distributes the frame to the appropriate logical link entity based on the 
DLCI. 

GSM 01.61 [2] contains the requirements for the GPRS ciphering algorithm. 



4.7.3 Logical Link Management 



The Logical Link Management Entity (LLME) manages the resources that have an impact on individual connections. 
There is one LLME per TLLI. Functions provided by the LLME are: 

- parameter initialisation; 

error processing; and 

connection flow control invocation. 

The RLC/MAC layer functions are described in GSM 03.64 [6]. BSSGP is specified in GSM 08.18. SNDCP is specified 
in GSM 04.65. 



4.8 GPRS Mobility Management 



GPRS Mobility Management (GMM) uses the services of the LLC layer to transfer messages between the MS and the 
SGSN. GMM includes functions such as attach and authentication, and transport of session management messages for 
functions such as PDP context activation and deactivation. GMM procedures are defined in GSM 04.08 and are beyond 
the scope of the LLC layer. Interaction between GMM and LLC is defined in terms of service primitives, see clause 7. 



4.9 Short Message Service 



The Short Message Service (SMS) uses the services of the LLC layer to transfer short messages between the MS and the 
SGSN. SMS procedures are defined in GSM 03.40 [4] and GSM 04.1 1 [9] and are beyond of the scope of the LLC 
layer. Interaction between SMS and LLC is defined in terms of service primitives, see clause 7. 



5 Frame structure 

5.1 General 

All logical link control layer peer-to-peer exchanges shall be in frames conforming to the format shown in Figure 3. The 
frame header shall consist of the address and control fields, and is a minimum of 2 octets and a maximum of 37 octets 
long. 
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8 7 6 5 4 3 2 1 



Address Field (1 octet) 



Cj3j]trol_ Field 

(variable length, max. 36 octets) 



Information Field 



(variable length, max. N201 octets) 



Frame Check Sequence Field 



(3 octets) 



Figure 3: LLC frame format 



5.2 



Address field 



The address field consists of a single octet. The address field contains the SAPI and identifies the DLCI for which a 
downlink frame is intended and the DLCI transmitting an uplink frame. The format of the address field is defined in 
subclause 6.2. 



5.3 



Control field 



The control field typically consists of between one and three octets. The SACK supervisory frame also includes a 
variable-length bitmap field of up to 32 octets. The format of the control field is defined in subclause 6.3. 



5.4 



Information field 



The information field of a frame, when present, follows the control field (see subclause 5.4 above). The maximum 
number of octets in the information field (N201) is defined in subclause 8.9.5. 

5.5 Frame Check Sequence (FCS) field 

The FCS field shall consist of a 24 bit cyclic redundancy check (CRC) code. The CRC-24 is used to detect bit errors in 
the frame header and information fields. 

The FCS field contains the value of a CRC calculation that is performed over the entire contents of the header and 
information for protected service. The FCS field contains the value of a CRC calculation that is performed over the 
frame header only for unprotected service (see subclause 6.3.5.5.2). The CRC calculation shall be done before ciphering 
at the transmitting side, and after deciphering at the receiving side. 

NOTE: The definition below is different from that in GSM 04.22 [10], since the LLC frame is variable-length 
with k bits. In GSM 04.22, the RLP frame is a fixed length 216 bits. 

The CRC shall be the ones complement of the sum (modulo 2) of: 

the remainder of x k (x 23 + x 22 + x 21 +. . . + x 2 + x + 1) divided (modulo 2) by the generator polynomial, where k is 
the number of bits of the information over which the CRC is calculated; and 

the remainder of the division (modulo 2) by the generator polynomial of the product of x 24 by the information 
over which the CRC is calculated. 

The CRC-24 generator polynomial is: 

G(x) = x 24 + x 23 + x 21 + x 20 + x 19 + x 17 + x 16 + x 15 + x 13 + x 8 + x 7 + x 5 + x 4 + x 2 +l 
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The result of the CRC calculation is placed within the FCS field as described in subclause 5.7.3. 

NOTE: As a typical implementation at the transmitter, the initial content of the register of the device computing 
the remainder of the division is pre-set to all "l's" and is then modified by division by the generator 
polynomial (as described above) of the information over which the CRC is to be calculated; the ones 
complement of the resulting remainder is put into the FCS field. 

As a typical implementation at the receiver, the initial content of the register of the device computing the remainder of 
the division is pre-set to all "l's". The final remainder, after multiplication by x 24 and then division (modulo 2) by the 
generator polynomial of the received frame, will be (in the absence of errors): 

C(x) = x 22 + x 21 + x 19 + x 18 + x 16 + x 15 + x 11 + x 8 + x 5 + x 4 



5.6 Transparency 
5.6.1 Bit transparency 



Because of the frame delimitation technique used in LLC, the frame can include any possible sequence of bits without 
the need for e.g., bit stuffing as defined in Q.921. 



5.6.2 Information protection 



The information carried within a UI frame may be considered as either "protected" or "unprotected" (see 

subclause 6.3.5.5.2). CRC error detection procedures are not used on information content within unprotected UI frames, 

supporting applications that can tolerate bit errors. 



5.6.3 Octet alignment 



LLC provides only an octet-aligned service to layer 3. LLC requires that information exchanged with layer 3 contains an 
integral number of octets. 



5.7 



Format convention 



5.7.1 



Numbering convention 



The basic convention used in this specification is illustrated in Figure 4. The bits are grouped into octets. The bits of an 
octet are shown horizontally and are numbered from 1 to 8. Multiple octets are shown vertically and are numbered from 
1 ton. 



Bit 

5 4 



1 Octet 

1 
2 



n-1 



Figure 4: Format convention 

5.7.2 Order of transmission 

Frames are transferred between the LLC layer and underlying protocol layers in units of octets, in ascending numerical 
octet order (i.e., octet 1, 2, ..., n-1, n). The order of bit transmission is specific to the underlying protocols used across 
the Um interface (e.g., RLC) and the Gb interface (BSSGP). 
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5.7.3 Field mapping convention 



When a field is contained within a single octet, the lowest bit number of the field represents the lowest-order value. 
When a field spans more than one octet, the order of bit values within each octet progressively decreases as the octet 
number increases. In that part of the field contained in a given octet the lowest bit number represents the lowest-order 
value. 

For example, a bit number can be identified as a couple (o, b) where o is the octet number and b is the relative bit 
number within the octet. Figure 5 illustrates a field that spans from bit (1, 3) to bit (2, 7). The high-order bit of the field 
is mapped on bit (1, 3) and the low-order bit is mapped on bit (2, 7). 



8 


7 


6 


Bit 

5 4 


3 


2 


1 




2 4 


2 3 


2 2 


2 1 


2° 





1st octet of field 
2nd octet of field 

Figure 5: Field mapping convention 

An exception to the preceding field mapping convention is the FCS field. In this case bit 1 of the first octet is the high- 
order bit and bit 8 of the last octet is the low-order bit. The field mapping for a 24 bit FCS is shown in Figure 5. 
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6 


Bit 

5 4 


3 


2 


1 


2 16 




2 23 


2 8 




2 15 


2° 




2 7 



1 st octet of field 
2nd octet of field 
3rd octet of field 



Figure 6: FCS mapping convention 



5.8 



Invalid frames 



An invalid frame is a frame that: 

contains fewer octets than necessary to include the address field, control field, information field, and FCS field 
necessary to constitute a complete frame according to the contents of the control field; 

- has the PD bit set to 1; 

contains a reserved SAPI; or 

contains an FCS error. 

An invalid frame shall be discarded without notification to the sender. No action shall be taken as the result of that 
frame. 



Elements of procedures and formats of fields 



6.1 



General 



The elements of procedures define the commands and responses that are used on the logical link connections between 
the MS and SGSN. 

Procedures are derived from these elements of procedures and are described in clause 8. 

If a bit position is marked as "spare", it shall be coded as 0. A spare bit is indicated with an 'X' in the format figures in 
this clause. For future compatibility reasons, an entity receiving frames, where spare bit positions are coded otherwise, 
shall ignore those values without notification of any error. 
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6.2 



Address field format and variables 



The address field consists of 

the Protocol Discriminator bit PD; 
the Command/Response bit C/R; and 
- the SAPI. 

The format of the address field is shown in Figure 7. 



Bit 



8 7 6 5 ■! 3 2 1 Octet 

1 



PD 


C/R 


X 


X 


SAPI 



Figure 7: Address field format 



6.2.1 Protocol Discriminator bit (PD) 



The PD bit indicates whether a frame is an LLC frame or belongs to a different protocol. LLC frames shall have the 
PD bit set to 0. If a frame with the PD bit set to 1 is received, then it shall be treated as an invalid frame, see 
subclause 5.8. 



6.2.2 Command/Response bit (C/R) 



The C/R bit identifies a frame as either a command or a response. The MS side shall send commands with the C/R bit 
set to 0, and responses with the C/R bit set to 1. The SGSN side shall do the opposite; i.e., commands are sent with C/R 
set to 1, and responses are sent with C/R set to 0. The combinations for the SGSN side and MS side are shown in 
Table 1. 

Table 1 : C/R field bit usage 



Type 


Direction 


C/R value 


Command 


SGSN side to MS side 


1 


Command 


MS side to SGSN side 





Response 


SGSN side to MS side 





Response 


MS side to SGSN side 


1 



6.2.3 Service Access Point Identifier (SAPI) 

SAPI identifies a point at which LLC services are provided by an LLE to a layer-3 entity. Consequently, SAPI identifies 
an LLE that should process an LLC frame and also a layer-3 entity that is to receive information carried by the LLC 
frame. 
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SAPI allows 16 service access points to be specified. The SAPI values are allocated as shown in Table 2. 

Table 2: Allocation of SAPI values 



SAPI 


Related Service 


SAP Name 


0000 


Reserved 


- 


0001 


GPRS Mobility Management 


LLGMM 


0010 


Reserved 


- 


0011 


User data 1 


LL3 


0100 


Reserved 


- 


0101 


User data 2 


LL5 


0110 


Reserved 


- 


0111 


SMS 


LLSMS 


1000 


Reserved 


- 


1001 


User data 3 


LL9 


1010 


Reserved 


- 


1011 


User data 4 


LL11 


1100 


Reserved 


- 


1101 


Reserved 


- 


1110 


Reserved 


- 


1111 


Reserved 


- 



6.3 Control field formats, parameters, and variables 

The control field identifies the type of frame. Four types of control field formats are specified: 
confirmed information transfer (I format); 
supervisory functions (S format); 
unconfirmed information transfer (UI format); and 
control functions (U format). 
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The control field formats for LLC are shown in Figure 8 and Figure 9. For definition of values for supervisory function 
bits and unnumbered function bits, see Table 4. 

Control Field Bits 



Format 
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7 
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5 


4 


3 


2 


1 


I format 





A 


X 


N(S) 


(I+S) 


N(S) 


X 


N(R) 




N(R) 


Si 


s 2 


S format 


1 





A 


X 


X 


N(R) 




N(R) 


Si 


s 2 


UI format 


1 


1 





X 


X 


N(U) 




N(U) 


E 


PM 


U format 


1 


1 


1 


P/F 


M 4 


M 3 


M 2 


Mi 



A Acknowledgement request bit 

E Encryption function bit 

M x Unnumbered function bit 

N(R) Transmitter receive sequence number 

N(S) Transmitter send sequence number 

N(U) Transmitter unconfirmed sequence number 

P/F Poll bit, when issued as a command, 
Final bit, when issued as a response 

PM Protected mode bit 

S x Supervisory function bit 

Figure 8: Control field format 
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R(250) 


R(251) 


R(252) 


R(253) 


R(254) 


R(255) 


X 


34 (max) 



Figure 9: SACK I and S frame control field format 



6.3.1 



Information transfer format - I 



The I format shall be used to perform an information transfer between layer-3 entities. The functions of N(S), N(R), and 
A are independent; that is, each I frame has an N(S) sequence number, an N(R) sequence number that may or may not 
acknowledge additional I frames received by the LLE, and a A bit that may be set to or 1 . The use of N(S), N(R), and 
A is defined in clause 8. 
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Each I frame also contains supervisory information, in effect "piggy-backing" an S frame with each I frame, so that it 
may be considered to be an I+S frame. 

6.3.2 Supervisory format - S 

The S format shall be used to perform logical link supervisory control functions such as acknowledge I frames and 
request a temporary suspension of I-frame transmission. The functions of N(R) and the A bit are independent; that is, 
each supervisory frame has an N(R) sequence number that may or may not acknowledge additional I frames received by 
the LLE, and an A bit that may be set to or 1. The use of N(R) and the A bit is described in clause 8. 

6.3.3 Unconfirmed Information format - Ul 

The UI format shall be used to perform an information transfer between layer-3 entities without acknowledgement. No 
verification of sequence numbers is performed for UI frames. Therefore, a UI frame may be lost without notification to 
the layer-3 entity if a logical link exception occurs during transmission of the frame. The information field may be 
encrypted or not as indicated by the E bit (see subclause 6.3.5.5.1). The frame also includes an PM bit that allows the 
transfer of unprotected information (see subclause 6.3.5.5.2). 

6.3.4 Unnumbered format - U 

The U format shall be used to provide additional logical link control functions. This format contains no sequence 
number. The format includes a P/F bit that may be set to or 1 . 

6.3.5 Control field parameters and associated state variables 

The various parameters associated with the control field formats are described in this subclause. 

6.3.5.1 Poll/Final bit (P/F) 

All U frames contain the Poll/Final (P/F) bit. The P/F bit serves a function in both command frames and response 
frames. In command frames the P/F bit is referred to as the P bit. In response frames it is referred to as the F bit. 

The P bit set to 1 is used by an LLE to solicit (poll) a response frame from the peer LLE. The F bit set to 1 is used by an 
LLE to indicate the response frame transmitted as a result of a soliciting (poll) command. 

The use of the P/F bit is described in clause 8. 

6.3.5.2 Acknowledgement request bit (A) 

All I and S frames contain the Acknowlegement Request (A) bit. 

The A bit set to 1 is used by an LLE to solicit an acknowledgement (i.e., an I+S or S frame) from the peer LLE. The 
A bit set to is used by an LLE to indicate that the peer LLE is not requested to send an acknowledgement. 

The use of the A bit is described in clause 8. 

6.3.5.3 Modulus 

Each I and UI frame is sequentially numbered by a sequence number that may have the value through 511. 

Arithmetic acting on parameters and variables that are related to such sequence numbers operates modulo 512 (i.e., 
N(S), N(R), N(U), V(S), V(R), V(A), V(U), V(UR); see the following subclauses). 

NOTE: Modulo 5 12 operation on negative numbers is performed by adding multiples of 5 12 to the negative 
number until the result becomes non-negative. Then common modulo 512 operation is applied. 
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6.3.5.4 ABM Variables and sequence numbers 

6.3.5.4.1 Send state variable V(S) 

In Asynchronous Balanced Mode, eachLLE peer shall have an associated send state variable V(S) when using I frames. 
V(S) denotes the sequence number of the next in-sequence I frame to be transmitted. V(S) can take on the value 
through 511. The value of V(S) shall be incremented by 1 with each successive I frame transmission, and shall not 
exceed V(A) by more than the maximum number of outstanding I frames k. The value of k may be in the range of 
1 < k < 256, as defined in subclause 8.9.7. V(S) shall not be incremented when an I frame is retransmitted. 

6.3.5.4.2 Acknowledge state variable V(A) 

In Asynchronous Balanced Mode, eachLLE peer shall have an associated acknowledge state variable V(A) when using 
I frame and supervisory frame commands and responses. V(A) identifies the first I frame in the transmit window, so that 
V(A) - 1 equals N(S) of the last in-sequence acknowledged I frame. V(A) can take on the value through 511. The 
value of V(A) shall be updated by the valid N(R) values received from its peer (see subclause 6.3.5.4.5). A valid N(R) 
value is one that is in the range V(A) < N(R) < V(S). 

These inequalities shall be interpreted in the following way: 

N(R) is valid if, and only if, ( N(R) - V(A) ) mod 512 < ( V(S) - V(A) ) mod 512. 

Furthermore, from subclause 6.3.5.4.1, ( V(S) - V(A) ) mod 512 < k. 

6.3.5.4.3 Send sequence number N(S) 

In Asynchronous Balanced Mode, only I frames contain N(S), the send sequence number of transmitted I frames. At the 
time that an in-sequence I frame is designated for transmission, the value of N(S) is set equal to the value of the send 
state variable V(S). 

6.3.5.4.4 Receive state variable V(R) 

In Asynchronous Balanced Mode, each LLE peer shall have an associated receive state variable V(R) when using 
I frame and supervisory frame commands and responses. V(R) denotes the sequence number of the next in-sequence 
I frame expected to be received. V(R) can take on the value through 511. The value of V(R) shall be incremented by 
one with the receipt of an error-free, in-sequence I frame whose send sequence number N(S) equals V(R). 

6.3.5.4.5 Receive sequence number N(R) 

In Asynchronous Balanced Mode, all I frames and supervisory frames contain N(R), the expected send sequence number 
of the next in-sequence received I frame. At the time that a frame of the above types is designated for transmission, the 
value of N(R) is set equal to the value of the receive state variable V(R). N(R) indicates that the LLE transmitting the 
N(R) has correctly received all I frames numbered up to and including N(R) - 1 . 

6.3.5.4.6 SACK bitmap R(n) 

In Asynchronous Balanced Mode, all I+S and S SACK frames contain R(n), the SACK bitmap. At the time that a SACK 
frame is designated for transmission, the value of each bit R(n) in the bitmap shall be set to or 1 depending on whether 
I frame number N(R) + n has been received or not. R(n) = 1 indicates that the LLE transmitting the SACK frame has 
correctly received I frame number N(R) + n. R(n) = indicates that the LLE transmitting the SACK frame has not 
correctly received I frame number N(R) + n. 

The SACK bitmap contains a maximum of 255 bits, or 32 octets, as shown in Figure 9. The bitmap shall be truncated so 
that only bitmap octets up to and including the last bitmap octet containing at least one bit set to 1 are transmitted. The 
trailing bitmap octets shall not be transmitted. 

The I+S SACK frame contains a bitmap length indicator K. K + 1 indicates the number of octets in the bitmap. K can 
take any value through 3 1 . 
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6.3.5.4.7 I frame buffer variable B 

In Asynchronous Balanced Mode, eachLLE peer shall have an associated I frame buffer variable B when using I frame 
and supervisory frame commands and responses. The value of B has a range of < B < M, where M is defined in 
subclause 8.9.6. 

Function L(x) gives the total information field length in octets of the I frame with sequence number x. B shall be 
incremented with L(x) of each transmitted I frame as defined in subclause 8.6.1. B shall be decremented by L(x) of each 
acknowledged I frame as defined in subclause 8.6.3.2. 

6.3.5.4.8 Other parameters and variables 

For definition and values of additional parameters and variables, see subclause 8.9. 

6.3.5.5 Unacknowledged operation variables and parameters 

6.3.5.5.1 Encryption mode bit (E) 

The E bit is used to indicate whether the information and FCS fields of the UI frame are encrypted (ciphered) to provide 
user data confidentiality. The E bit is set to 1 to indicate an encrypted frame. The E bit is set to to indicate a frame sent 
without encryption. 

6.3.5.5.2 Protected mode bit (PM) 

The PM bit is used to indicate whether the FCS field shall be calculated using both the frame header and information 
fields. The PM bit is set to 1 to indicate that the FCS field covers the frame header and information fields. The PM bit is 
set to to indicate that the FCS field covers only the frame header field. This permits UI frames to transport 
"unprotected" information, such that errors within the information field do not result in the frame being discarded. 

Table 3: UI frame content 



PM 


E 


UI frame information field 








unprotected, non-ciphered information 





1 


unprotected, ciphered information 


1 





protected, non-ciphered information 


1 


1 


protected, ciphered information 



6.3.5.5.3 Unconfirmed send state variable V(U) 

Each LLE peer shall have an associated unconfirmed send state variable V(U) when using UI frame commands. V(U) 
denotes the sequence number of the next UI frame to be transmitted. V(U) can take on the value through 511. The 
value of V(U) shall be incremented by 1 with each successive UI frame transmission. 

6.3.5.5.4 Unconfirmed sequence number N(U) 

Only UI frames contain N(U), the unconfirmed sequence number of transmitted UI frames. At the time that a UI frame is 
designated for transmission, the value of N(U) is set equal to the value of the unconfirmed send state variable V(U). 

6.3.5.5.5 Unconfirmed receive state variable V(UR) 

Each LLE peer shall have an associated unconfirmed receive state variable V(UR) when using UI frame commands. 
V(UR) denotes the sequence number of the next in-sequence UI frame expected to be received. V(UR) can take on the 
value through 511. 

6.3.5.5.6 Other parameters and variables 

The only other parameter defined for unacknowledged operation is the number of octets (N201-U) in the information 
field of the UI frame. See subclause 8.9.4. 
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6.4 Commands and responses 



The following commands and responses are used by the MS and the SGSN LLEs and are represented in Table 4. Each 
logical link connection shall support the appropriate set of commands and responses for the type of operation desired 
(see clause 8). 

Those frame types not identified in Figure 8, Figure 9, or Table 4, shall be identified as having undefined command 
and/or response control fields, and shall be treated as defined in subclause 8.8.2. 

Table 4: Commands and responses 



Format 


Commands 


Responses 


S1 


S2 


Encoding 
M4 M3 


M2 


M1 


Information + 
Supervisory 


RR 


RR 








- 


- 


- 


- 


ACK 


ACK 





1 


- 


- 


- 


- 


RNR 


RNR 


1 





- 


- 


- 


- 


SACK 


SACK 


1 


1 


- 


- 


- 


- 


Unnumbered 


- 


DM 


- 


- 











1 


DISC 


- 


- 


- 





1 








- 


UA 


- 


- 





1 


1 





SABM 


- 


- 


- 





1 


1 


1 


- 


FRMR 


- 


- 


1 











XID 


XID 


- 


- 


1 





1 


1 



The commands and responses in Table 4 are defined in the following subclauses. 



6.4.1 Unnumbered (U) frames 



6.4.1.1 



Set asynchronous balanced mode (SABM) command 



The SABM unnumbered command shall be used to place the addressed MS or SGSN side into ABM acknowledged 
operation. 

An LLE shall confirm acceptance of a SABM command by the transmission at the first opportunity of a UA response. 
Upon acceptance of this command, the LLE's send state variable V(S), acknowledge state variable V(A), and receive 
state variable V(R), shall be set to 0. The transmission of a SABM command indicates the clearance of any exception 
condition, and a busy condition that was reported by the earlier transmission of an RNR frame by that same LLE. 

Previously transmitted I frames that are unacknowledged when this command is actioned shall remain unacknowledged 
and shall be discarded. It is the responsibility of a higher layer to recover from the possible loss of the contents of such 
I frames. 

An information field is permitted with the SABM command. If included, the information field shall contain XID 
parameters. This allows the LLC peers to negotiate LLC layer parameters with the SABM command and UA response, 
using the procedure (but not the XID frames) defined in subclauses 6.4.1.6 and 8.5.3. 



6.4.1.2 



Disconnect (DISC) command 



The DISC unnumbered command shall be transmitted in order to terminate the ABM operation. 

No information field is permitted with the DISC command. Prior to executing the command, the LLE receiving the 
DISC command shall confirm the acceptance of a DISC command by the transmission of a UA response. The LLE 
sending the DISC command shall terminate the ABM operation when it receives the acknowledging UA or DM 
response. 

Previously transmitted I frames that are unacknowledged when this command is executed shall remain unacknowledged 
and shall be discarded. It is the responsibility of a higher layer to recover from the possible loss of the contents of such 
I frames. 
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6.4.1.3 



Unnumbered Acknowledgement (UA) response 



The UA unnumbered response shall be used by an LLE to acknowledge the receipt and acceptance of the mode-setting 
commands (SABM or DISC). Received mode-setting commands are not actioned until the UA response is transmitted. 

An information field is only permitted when UA is the response to a SABM command. The UA response shall in this 
case contain XID parameters with negotiated XID values, using the procedure (but not the XID frames) defined in 
subclauses 6.4.1.6 and 8.5.3. 

The transmission of the UA response indicates the clearance of any busy condition that was reported by the earlier 
transmission of an RNR frame by that same LLE. 



6.4.1.4 



Disconnected Mode (DM) response 



The DM unnumbered response shall be used by an LLE to report to its peer that the LLE is in a state such that ABM 
operation cannot be performed. An LLE shall transmit a DM response to any valid command received that it cannot 
action. 

No information field is permitted with the DM response. 



6.4.1.5 



Frame Reject (FRMR) Response 



The FRMR unnumbered response may be received by an LLE as a report of a frame rejection condition not recoverable 
by retransmission of the identical frame: 

1) receipt of a command or response control field that is undefined or not implemented (see subclause 6.4, second 
paragraph); 

2) receipt of a supervisory or unnumbered frame with incorrect length; or 

3) receipt of an I frame with an information field that exceeds the maximum established length. 

An undefined control field is any of the control field encodings that are not identified in Figure 8, Figure 9, or Table 4. 

An information field that immediately follows the control field and that consists of 10 octets shall be returned with this 
response to provide the reason for the FRMR response. This information field format is given in Figure 10. Only the 
first 6 octets of the control field of the rejected frame shall be sent. If the control field of the rejected frame is fewer than 
6 octets, then the unused octets shall be set to 0. 



Octet 
I 

2 
3 
4 
5 
6 
7 



10 



8 


7 


6 


Bit 

5 4 


3 


2 


1 


Rejected frame 
control field 


X 


X 


X 


X 


V(S) 


V(S) 


X 


V(R) 


V(R) 


C/R 


X 


X 


X 


X 


X 


W3 


W2 


Wl 



Figure 10: FRMR frame information field format 
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The information fields defined for the FRMR response are listed in Table 5. 

Table 5: FRMR frame fields 



Field 


Description 


Rejected frame control field 


The control field of the received frame that caused the frame reject. 


V(S) 


The current send state variable value of the LLE reporting the rejection condition. 


V(R) 


The current receive state variable value of the LLE reporting the rejection condition. 


C/R 


Set to 1 if the frame rejected was a response and set to if the frame rejected was a 
command. 


W1 


Set to 1 to indicate that the control field received and returned in octets 1 and 2 was 
considered invalid because the frame contained an information field that is not permitted 
within this frame or is a supervisory or unnumbered frame with incorrect length. Bit W4 
shall be set to 1 in conjunction with this bit. 


W2 


Set to 1 to indicate that the information field received exceeded the maximum 
established information field length (N201) of the LLE reporting the rejection condition. 


W3 


Set to 1 to indicate that the control field received and returned in octets 1 and 2 was 
undefined or not implemented. 



6.4.1.6 



Exchange Identification (XID) command/response 



This frame shall be used to negotiate and re-negotiate LLC layer parameters and layer-3 parameters. XID frames can be 
transmitted in ADM and ABM. 

The negotiation procedure is one-step, i.e., one side shall start the process by sending an XID command, offering a 
certain set of parameters from the applicable parameter repertoire (see Table 6) the sending entity wants to negotiate, 
proposing values within the allowed range. In return, the other side shall send an XID response, either confirming these 
parameter values by returning the requested values, or offering higher or lower ones in their place. See Table 6 for sense 
of negotiation. Parameters that are not commented upon by the responding side shall be treated as if the defaultvalues 
(see Table 9) were returned. This shall end the negotiation process. 

Both entities shall support the negotiated values, however under certain conditions one or more parameters may need to 
be re-negotiated (e.g., in the case of a change in SGSN). 

XID frames shall always be used with the P/F bit set to 1 . 

Without any prior XID exchange, default values shall apply. 

Negotiated XID parameters shall apply to the LLE identified by the DLCI of the XID frames used, except Version and 
IOV-UI that applies to an LLME (i.e., a TLLI), and except Layer 3 Parameters that apply to the layer 3 above the LLE. 

Table 6 lists the negotiable LLC layer parameters. Figure 1 1 shows the format of the XID information field. 



8 


7 


Bit 

6 5 4 


3 


2 


1 


XL 


Parameter Type 


Length 


Length 


X 


X 


High-order octet 




Low-order octet 



Octet 

1 

2 
2 or 3 



Figure 11 : XID parameter field format 

A parameter item consists of one or two type/length octets followed by the value of that parameter. The XID Length 
(XL) bit indicates whether the Length field is 2 bits or 8 bits long. If XL is set to 0, then Length consists of 2 bits and 
type/length occupies one octet. If XL is set to 1 then Length consists of 8 bits and type/length occupies two octets. The 
length indicator gives the number of octets that the value actually occupies. The parameter items can be arranged in 
arbitrary order. The parameter items shall begin in the first octet of the XID information field and follow on 
contiguously. 
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Table 6: LLC layer parameter negotiation 



Parameter Name 


Type 


Length 


Format 
(87654321) 


Range 


Units 


Sense of 
Negotiation 


Version (LLC version 
number) 





1 


OOOObbbb 


through 
15 


- 


down 


IOV-UI (ciphering Input 
offset value for Ul 
frames), common for all 
SAPIs of a TLLI 


1 


4 


bbbbbbbb 
bbbbbbbb 
bbbbbbbb 
bbbbbbbb 


through 
2 32 -1 






IOV-I (ciphering Input 
offset value for I frames), 
for the SAPI under 
negotiation 


2 


4 


bbbbbbbb 
bbbbbbbb 
bbbbbbbb 
bbbbbbbb 


through 
2 32 -1 






T200 (retransmission 
time-out) 


3 


2 


OOOObbbb 
bbbbbbbb 


1 through 
4 095 


0.1 seconds 


up 


N200 (maximum number 
of retransmissions) 


4 


1 


OOOObbbb 


1 through 
15 


- 


up 


N201-U (maximum 
information field length 
for U and Ul frames) 


5 


2 


OOOOObbb 
bbbbbbbb 


140 

through 

1 520 


octets 


down 


N201-I (maximum 
information field length 
for I frames) 


6 


2 


OOOOObbb 
bbbbbbbb 


140 

through 

1 520 


octets 


down 


mD (I frame buffer size in 
the downlink direction) 


7 


2 


Obbbbbbb 
bbbbbbbb 


through 
24 320 


1 6 octets 


down 


mU (I frame buffer size in 
the uplink direction) 


8 


2 


Obbbbbbb 
bbbbbbbb 


through 
24 320 


1 6 octets 


down 


kD (window size in the 
downlink direction) 


9 


2 


0000000b 
bbbbbbbb 


1 through 
256 


frames 


down 


kU (window size in the 
uplink direction) 


10 


2 


0000000b 
bbbbbbbb 


1 through 
256 


frames 


down 


Layer-3 Parameters 


11 


Variable 


See GSM 04.65 


- The Range for N201 -U for SAPIs 1 and 7 is 270 through 1 520 octets. 

All other Types and Ranges are reserved for future versions of this specification. 

The length for Layer-3 Parameters shall be set equal to the number of octets received from layer 3. 



Version shall not be negotiated while in ABM. 

IOV-UI shall only be negotiated in ADM, and only before ciphering is enabled. IOV-I shall only be negotiated with 
XID parameters carried in SABM and UA frames. IOV-UI and IOV-I shall only be transmitted in the downlink 
direction. The lack of IOV-UI in the uplink direction shall not be understood as a request to use the default value. 

T200, N200, and N201-U can be negotiated in ADM and ABM. The new values of T200 shall only apply to timers set 
after the negotiation has been completed. 

N201-I, mD, mU, kD, and kU can be negotiated to any value in Range in ADM. In ABM, N201-I, mD, mU, kD, and kU 
can only be negotiated to the same or higher value as previously used. 

6.4.2 Unconfirmed Information (Ul) frame 



6.4.2.1 



Unconfirmed Information (Ul) command 



When a layer-3 entity requests unacknowledged information transfer, the Ul command shall be used to send information 
to its peer. No verification of sequence numbers is performed for Ul frames. Therefore, the Ul frame may be lost 
without notification to the layer-3 entity if a logical link exception occurs during transmission of the command. 

6.4.3 Combined Information (I) and Supervisory (S) frames 

The function of the information (I) frame is to transfer, across a logical link connection, sequentially-numbered frames 
containing information fields provided by layer 3. This frame shall only be used in the ABM operation. 
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Numbered I frames shall also carry supervisory information, and are for this reason also called I+S frames. A separate 
S frame is sent when there is no information field to be transferred. Whether an I+S or S frame is transmitted as a 
command or as a response is insignificant in the ABM procedures. 

6.4.3.1 Receive Ready (RR) command / response 

The receive ready (RR) supervisory frame is used by an LLE to: 

indicate that it is ready to receive an I frame; and 

acknowledge previously received I frames numbered up to and including N(R) - 1 (as defined in clause 8). 

In addition to indicate the status of an LLE, the RR frame with the A bit set to 1 may be used by the LLE to request an 
ackowledgement from its peer LLE. 

The transmission of an RR frame shall also indicate the clearance of any busy condition within the sending LLE that was 
reported by the earlier transmission of an RNR frame by the same LLE. 

6.4.3.2 Acknowledgement (ACK) command / response 

The ACK supervisory frame shall be used by an LLE to acknowledge a single or multiple I frames. Frames up to and 
including N(R) - 1, and frame N(R) + 1, have been received correctly. The procedures associated with the ACK control 
field are defined in subclause 8.6.3. 

In addition to indicate the status of an LLE, the ACK frame with the A bit set to 1 may be used by the LLE to request an 
ackowledgement from its peer LLE. 

The transmission of an ACK frame shall also indicate the clearance of any busy condition within the sending LLE that 
was reported by the earlier transmission of an RNR frame by the same LLE. 

6.4.3.3 Selective Acknowledgement (SACK) command / response 

The SACK supervisory frame shall be used by an LLE to acknowledge a single or multiple I frames. Frames up to and 
including N(R) - 1, and frames indicated by the SACK bitmap, have been received correctly. The format of the SACK 
control field is shown in Figure 9. The procedures associated with the SACK control field are defined in 
subclause 8.6.3. 

In addition to indicate the status of an LLE, the SACK frame with the A bit set to 1 may be used by the LLE to request 
an ackowledgement from its peer LLE. 

The transmission of a SACK frame shall also indicate the clearance of any busy condition within the sending LLE that 
was reported by the earlier transmission of an RNR frame by the same LLE. 

6.4.3.4 Receive not ready (RNR) command / response 

The receive not ready (RNR) supervisory frame shall be used by an LLE to indicate a busy condition; that is, a 
temporary inability to accept additional incoming I frames. The value of N(R) in the RNR frame acknowledges I frames 
numbered up to and including N(R) - 1. Subsequent frames, if any, shall not be considered confirmed. The acceptance 
status of those is a matter of further status exchange. 

In addition to indicate the status of an LLE, the RNR frame with the A bit set to 1 may be used by the LLE to request an 
ackowledgement from its peer LLE. 
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7 Elements for layer-to-layer communication 

7.1 Definition of service primitives and parameters 

Communications between layers and between entities within the logical link control layer are accomplished by means of 
service primitives. Service primitives represent, in an abstract way, the logical exchange of information and control 
between the logical link control layer and adjacent layers. They do not specify or constrain implementations. 

Service primitives consist of commands and their respective responses associated with the services requested of another 
layer. The general syntax of a primitive is: 

XXX - Generic name - Type (Parameters) 

where XXX designates the service access point between the LLC layer and the layer providing or using the service. For 
this specification XXX is: 

- "LLGMM" for the SAP between the LLC layer and the GPRS mobility management function; 

- "LL" for the SAPs between the LLEs and layer 3; 

- "GRR" for the SAP between the LLC layer and the RLC/MAC layer; and 

- "BSSGP" for the SAP between the LLC layer and the BSSGP layer. 

7.1.1 Primitives types 

The primitives types defined in this specification are: 

NOTE: For the action sequence of these primitive types, see GSM 04.01 [7]. 

7.1.1.1 Request 

The Request primitive type is used when a higher layer is requesting a service from the next lower layer. 

7.1.1.2 Indication 

The Indication primitive type is used by a layer providing a service to notify the next higher layer of activities related to 
the Request primitive type of the peer. 

7.1.1.3 Response 

The Response primitive type is used by a layer to acknowledge receipt, from the next lower layer, of the Indication 
primitive type. 

7.1.1.4 Confirm 

The Confirm primitive type is used by the layer providing the requested service to confirm that the activity has been 
completed (successfully or unsuccessfully). 
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7.1.2 Generic names 

The generic name specifies the activity that the identified layer should perform. Table 7 lists the primitives defined in 
this specification. 

Table 7: LLC layer service primitives 



Generic Name 


Location 


Type 


Parameters 


MS SGSN 


REQ IND RES CNF 


LLGMM <> LLM 


LLGMM-ASSIGN 


X 


X 


X 








TLLI Old, TLLI New, Kc, RAND, 
Ciphering Algorithm 


LLGMM-TRIGGER 


X 




X 








TLLI, Cause 


LLGMM-TRIGGER 


X 






X 






TLLI 


LLGMM-TRIGGER 




X 




X 






TLLI, Cell Id 


LLGMM-SUSPEND 


X 




X 








TLLI 


LLGMM-SUSPEND 




X 


X 








TLLI, Page 


LLGMM-RESUME 


X 


X 


X 








TLLI 


LLGMM-PAGE 




X 




X 






TLLI 


LLGMM-WINDOW 


X 




X 








TLLI, V(R)s 


LLGMM-WINDOW 




X 


X 








TLLI 


LLGMM-WINDOW 


X 


X 








X 


TLLI, V(R)s 


LLGMM-IOV 




X 


X 






X 


TLLI 


LLGMM-STATUS 


X 


X 




X 






TLLI, Cause 


GMM <-» LL, SNDCP <-» LL, and SMS <-» LL 


LL-ESTABLISH 


X 


X 


X 








TLLI, XID Req 


LL-ESTABLISH 


X 


X 




X 






TLLI, XID Req, N201-I, N201-U 


LL-ESTABLISH 


X 


X 






X 




TLLI, XID Neg 


LL-ESTABLISH 


X 


X 








X 


TLLI, XID Neg, N201-I, N201-U 


LL-RELEASE 


X 


X 


X 








TLLI, Local 


LL-RELEASE 


X 


X 




X 




X 


TLLI 


LL-XID 


X 


X 


X 








TLLI, XID Req 


LL-XID 


X 


X 




X 






TLLI, XID Req, N201-I, N201-U 


LL-XID 


X 


X 






X 




TLLI, XID Neg 


LL-XID 


X 


X 








X 


TLLI, XID Neg, N201-I, N201-U 


LL-DATA 


X 


X 


X 








TLLI, L3-PDU, Reference 


LL-DATA 


X 


X 




X 






TLLI, L3-PDU 


LL-DATA 


X 


X 








X 


TLLI, Reference 


LL-DATASENT 




X 




X 






TLLI, Reference, V(S) 


LL-UNITDATA 


X 


X 


X 








TLLI, L3-PDU, Data Mode, Cipher 


LL-UNITDATA 


X 


X 




X 






TLLI, L3-PDU, Cipher 


LL <-> RLC/MAC 


GRR-DATA 


X 




X 








TLLI, LL-PDU, SAPI, Cause 


GRR-DATA 


X 






X 






TLLI, LL-PDU 


GR-UNITDATA 


X 




X 








TLLI, LL-PDU, SAPI 


GR-UNITDATA 


X 






X 






TLLI, LL-PDU 


GRR-STATUS 


X 






X 






TLLI, Cause 


LL <-> BSSGP 


BSSGP-UNITDATA 




X 


X 








TLLI, LL-PDU, RLC Confirm, SAPI 


BSSGP-UNITDATA 




X 




X 






TLLI, LL-PDU, Cell Id 


BSSGP-STATUS 




X 




X 






TLLI, Cause 



7.2 Primitive procedures 
7.2.1 GMM - LLC primitives 



7.2.1.1 



LLGMM-ASSIGN 



The LLGMM-ASSIGN primitive shall be used by the GPRS mobility management entity to assign, change, or unassign 
the TLLI, the ciphering key (Kc) and the ciphering algorithm. 
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The TLLI Old and TLLI New parameters shall be interpreted as follows: 

If TLLI Old = all l's and TLLI New ^ all l's then TLLI New shall be assigned and used when transmitting LLC 
frames. If a TLLI Old + all l's was associated with TLLI New then TLLI Old is unassigned. Only TLLI New 
shall be accepted when received from the peer. 

If TLLI Old + all l's and TLLI New + all l's then TLLI Old and TLLI New are assigned and associated, and 
TLLI New shall be used when transmitting LLC frames. Both TLLI Old and TLLI New shall be accepted when 
received from the peer. 

- If TLLI Old * all l's and TLLI New = all l's then TLLI Old shall be unassigned, and all DLCIs related to TLLI 
Old shall be reset without transmission of any LLC frames. 

An LLC frame received with a DLCI belonging to an unassigned TLLI shall be discarded without any further actions, 
with the following exception: UI and XID frames with TLLI = unassigned and SAPI = 1 received in the SGSN shall be 
handled according to the LLC protocol. 

Kc and Ciphering Algorithm are associated with TLLI New (and TLLI Old if associated with TLLI New): 

If Ciphering Algorithm indicates no ciphering, then the ciphering function shall be disabled. 

Otherwise, the ciphering function shall be enabled. If a Ciphering Algorithm was already associated with TLLI 
New or TLLI Old, then the new Kc shall replace the previous Kc, and Ciphering Algorithm shall replace the 
previous algorithm selection. All I frames, and UI frames with the E bit set to 1, shall use the new Kc and 
algorithm for ciphering. All unacknowledged I frames shall be ciphered using the new Kc and algorithm before 
retransmission. As an implementation option, the previous Kc and algorithm may be used to decipher received 
frames. 

7.2.1.2 LLGMM-TRIGGER 

LLGMM-TRIGGER-REQ shall be used in the MS to order LLC to transmit any single frame. If there is a frame waiting 
to be transmitted in the MS, this frame shall be transmitted. Otherwise, and if the LLE is in ABM state, a supervisory 
frame shall be transmitted according to subclause 8.6.4.1. If the LLE is in ADM state a UI frame with no information 
field shall be transmitted. There is only need to transmit a frame on one SAPI. Which SAPI to choose is implementation 
dependent. 

LLGMM-TRIGGER-REQ is normally used for cell updates or for page responses, and the reason shall be indicated in 
the Cause parameter. If Cause indicates page response, then the GRR-DATA-REQ Cause parameter shall also indicate 
page response. 

The LLME in the MS shall send LLGMM-TRIGGER-IND to GMM every time an LL-PDU is transmitted, i.e., every 
time a GRR-DATA-REQ or GRR-UNITDATA-REQ is delivered to the lower layer. The LLME in the SGSN shall send 
LLGMM-TRIGGER-IND to GMM every time a valid LL-PDU is received, i.e., every time a BSSGP-UNITDATA-IND 
containing a valid LL-PDU is received (see subclause 5.8). 

NOTE: LLGMM-TRIGGER-IND moves the GMM Context to READY state and sets the READY timer in 
GMM. 

7.2.1.3 LLGMM-SUSPEND 

LLGMM-SUSPEND-REQ shall be used to order LLC to suspend operation for an MS until LLGMM-RESUME-REQ is 
received. While suspended, LLC shall: 

save L3-PDUs if any are buffered; 

save unacknowledged I frames; 

save the state of the state variables (e.g., the transmit and receive counters); 

- reset timer T200; and 
stop frame transmission. 
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Frame reception shall still be possible. For SAPI = 1, ADM procedures including UI frame transmission shall still be 
possible. The Page parameter controls whether LLGMM-PAGE-IND shall be sent to GMM or not (see 
subclause 7.2.1.5). 

7.2.1.4 LLGMM-RESUME 

LLGMM-RESUME-REQ shall be used to order LLC to resume a suspended operation for an MS without loss of the 
L3-PDUs or I frames that were saved when LLGMM-SUSPEND-REQ was received. If timer T200 was reset upon 
reception of LLGMM-SUSPEND-REQ then timer T200 shall be set. 

7.2.1.5 LLGMM-PAGE 

If the Page parameter received in the LLGMM-SUSPEND-REQ primitive is set to true, LLGMM-PAGE-IND shall be 
sent to GMM in the SGSN whenever LLC has an LL-PDU ready for transmission and LLC operation is suspended. The 
LL-PDU shall not be transmitted until LLGMM-RESUME-REQ has been received from GMM. 

If the Page parameter is set to false, LLGMM-PAGE-IND shall not be sent, and the LL-PDU shall not be transmitted 
until LLGMM-RESUME-REQ has been received from GMM. 

NOTE: LLGMM-PAGE-IND causes GMM to initiate paging of the MS . 

7.2.1.6 LLGMM-WINDOW 

LLGMM-WINDOW shall be used by GMM to fetch the receive state variable V(R) of the DLCIs in ABM. In the MS, 
LLGMM-WINDOW-REQ shall additionally be used to deliver V(R) values received from the SGSN via GMM 
procedures. The LLEs shall treat the V(R) values received as acknowledgements for all the I frames transmitted with an 
N(S) up to and including the received V(R) - 1 . 

7.2.1.7 LLGMM-IOV 

LLGMM-IOV-REQ shall be used to order LLC in the SGSN to perform an XID negotiation of IOV-UI. The LLC layer 
shall randomly select the value of IOV-UI. 

LLGMM-IOV-CNF shall be used to inform GMM in the SGSN that a successful XID negotiation of IOV-UI has been 
made. 

7.2.1.8 LLGMM-STATUS 

LLGMM-STATUS-IND shall be used to inform GMM when an LLC error that cannot be corrected by the LLC layer 
has occurred, or when LLC cannot continue its operation due to errors at the RLC/MAC or BSSGP layers as indicated 
with GRR-STATUS-IND or BSSGP-STATUS-IND. 

7.2.2 Layer 3 - LL primitives 

7.2.2.1 LL-ESTABLISH 

The LL-ESTABLISH primitives shall be used to request, indicate, respond to, and confirm establishment of ABM 
operation. XID Req and XID Neg are used to negotiate layer-3 XID parameters between the layer-3 peers, see 
GSM 04.65. 

7.2.2.2 LL-RELEASE 

The LL-RELEASE primitives shall be used to request, indicate, and confirm termination of a previously established 
ABM operation. The Local parameter indicates whether the termination shall be local, i.e., a DISC frame shall not be 
transmitted, or not local, i.e., a DISC frame shall be transmitted. 
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7.2.2.3 LL-XID 

The LL-XID primitives shall be used to request, indicate, respond to, and confirm negotiation of layer-3 XID 
parameters. 

7.2.2.4 LL-DATA 

The LL-DATA primitives shall only be used for LLEs in ABM. The following operations are defined: 

- LL-DATA-REQ shall be used to request the confirmed transmission of a L3-PDU to the peer; 

LL-DATA-IND shall be used to deliver a correctly received L3-PDU to layer 3; and 

LL-DATA-CNF shall be used to confirm the successful reception of a L3-PDU in the peer LLE. The Reference 
parameter shall be set to the same value as the Reference parameter received in the corresponding LL-DATA- 
REQ. 

7.2.2.5 LL-DATASENT 

LL-DATASENT-IND shall be used to indicate to layer 3 the V(S) assigned to an I frame. The Reference parameter shall 
be set to the same value as the Reference parameter received in the corresponding LL-DATA-REQ primitive. 

7.2.2.6 LL-UNITDATA 

LL-UNITDATA-REQ shall be used to request the unconfirmed transmission of a L3-PDU to the peer. The Data Mode 
parameter indicates whether the UI frame carrying the L3-PDU shall be transmitted in protected or unprotected mode, 
and whether RLC/MAC acknowledged or unacknowledged mode shall be used. The Cipher parameter indicates whether 
the UI frame shall be ciphered or not. 

LL-UNITDATA-IND shall be used to deliver a L3-PDU received in a UI frame to layer 3. The Cipher parameter 
indicates whether the received UI frame was ciphered or not. 



7.2.3 LL - RLC/MAC primitives 



Although the GRR-DATA or GRR-UNITDATA primitives are used in all LLC frame transfer operations, for simplicity 
reasons they are not included in the procedure descriptions in clause 8. 

7.2.3.1 GRR-DATA 

GRR-DATA-REQ shall be used by an LLE in an MS to request the reliable transmission of an LL-PDU. SAPI indicates 
the SAPI of the LLE. Cause indicates whether GRR-DATA-REQ is sent due to a page response. 

GRR-DATA-IND shall be used by the RLC/MAC layer in an MS to indicate the successful reception of an LL-PDU. 
The LL-PDU was completely received without errors detected by the RLC layer. 

All LLC frames except UI frames for SAPIs 3, 5, 9, and 11 shall be transferred with GRR-DATA primitives. All 
UI frames for SAPIs 3, 5, 9, and 11 shall be transferred with GRR-DATA or GRR-UNITDATA primitives. 

7.2.3.2 GRR-UNITDATA 

GRR-UNITDATA-REQ shall be used by an LLE in an MS to request the unreliable transmission of a UI frame. SAPI 
indicates the SAPI of the LLE. 

GRR-UNITDATA-IND shall be used by the RLC/MAC layer in an MS to indicate the reception of a UI frame. 

Only UI frames for SAPIs 3, 5, 9, and 1 1 shall be transferred with GRR-UNITDATA primitives. 
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7.2.3.3 GRR-STATUS 

GRR-STATUS-IND indicates that the RLC/MAC layer is unable to deliver data. The LLC layer shall, if possible, 
continue its operation. 

7.2.4 LL - BSSGP primitives 

Although the BSSGP-UNITDATA primitives are used in all LLC frame transfer operations, for simplicity reasons they 
are not included in the procedure descriptions in clause 8. 

7.2.4.1 BSSGP-UNITDATA 

BSSGP-UNITDATA-REQ shall be used by an LLE in an SGSN to request the transmission of an LL-PDU. RLC 
Confirm indicates whether the request shall be mapped into a GRR-DATA-REQ or GRR-UNITDATA-REQ primitive in 
the BSS. SAPI indicates the SAPI of the LLE. 

All LLC frames except UI frames for SAPI 3, 5, 9 and 1 1 shall be transferred with RLC Confirm indicating mapping 
into GRR-DATA-REQ primitive. All UI frames for SAPIs 3, 5, 9, and 1 1 shall be transferred with RLC Confirm 
indicating mapping into a GRR-DATA-REQ or GRR-UNITDATA-REQ primitives. 

BSSGP-UNITDATA-IND shall be used by the BSSGP layer in an SGSN to indicate the reception of an LL-PDU. Cell 
Id indicates the location of the MS when the LL-PDU was transmitted. 

7.2.4.2 BSSGP-STATUS 

BSSGP-STATUS-IND indicates that the BSSGP layer is unable to deliver data. The LLC layer shall, if possible, 
continue its operation. 

7.2.5 LLM - LL primitives 

The primitives that co-ordinate activities between the LLM and LL entities are not described. Implementations shall 
perform the necessary co-ordination between GMM <-> LLM primitives and LL operation. 



8 Definition of the LLC peer-to-peer protocol 

8.1 General 

In the following subclauses, a protocol for use by the GPRS logical link control layer between the SGSN and MS is 
specified, referred to as "LLC". 

The LLC elements of procedure (frame types) that apply are: 

for unacknowledged information transfer: 

UI command; and 

for ABM acknowledged information transfer: 

- SABM command; 

- UA response; 
DM response; 
DISC command; 

RR command / response; 
RNR command / response; 
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ACK command / response; 
SACK command / response; 
I command / response; and 
for both unacknowledged and acknowledged information transfer: 

FRMR response; and 
- XID command /response. 
For handling of timers, the procedures and terminology of Z. 100 [15] are used: 
Set <timer name> means that: 

a) if the timer is inactive, the timer becomes active, i.e., a timer value is associated with the timer and it starts 
running; and 

b) if the timer is active, the timer is first reset as in c) below, and then set as in a) above. 
Reset <timer name> means that: 

c) if the timer is active, the timer becomes inactive, i.e., the association with the timer value is lost and it stops 
running; and 

d) if the timer is inactive, it remains inactive. 



8.2 



Procedure for the use of the P/F bit 



Timer T200 shall be set when a command frame with the P bit set to 1 is transmitted. An LLE receiving a command 
frame with the P bit set to 1 shall set the F bit to 1 in the next response frame it transmits. 



8.3 TLLI assignment procedures 



TLLI assignment and unassignment is further described in clause 7 and annex B. The following two subclauses illustrate 
the TLLI assignment and unassignment procedures. 



8.3.1 TLLI assignment 



GMM shall assign a TLLI by sending an LLGMM-ASSIGN-REQ (TLLI New * all l's) primitive to LLME. Upon 
receiving LLGMM-ASSIGN-REQ, LLME shall enter the TLLI Assigned state and all its LLEs shall enter the ADM 
state. TLLI assignment is illustrated in Figure 12. 
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Figure 12: TLLI assignment procedure 
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8.3.2 TLLI change 



This procedure is used to change from a previously assigned TLLI value to a new TLLI value. GMM shall change TLLI 
by sending an LLGMM-ASSIGN-REQ (TLLI Old ± all l's, TLLI New * all l's) primitive to LLME. Upon receiving 
LLGMM-ASSIGN-REQ, LLME and all its LLEs shall not change their states. This is illustrated in Figure 14. 
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Figure 13: TLLI change procedure 



8.3.3 TLLI unassignment 



This procedure is used to unassign a previously assigned TLLI value. GMM shall unassign a TLLI by sending an 
LLGMM-ASSIGN-REQ (TLLI New = all l's) primitive to LLME. Upon receiving LLGMM-ASSIGN-REQ, LLME and 
all its LLEs shall enter the TLLI Unassigned state. This is illustrated in Figure 14. 
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Figure 14: TLLI unassignment procedure 



8.4 Procedures for unacknowledged information transfer 

The procedures that apply to the unacknowledged transmission of information are defined below. No LLC layer error 
recovery procedures are defined for unacknowledged operation. 
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Figure 15: Unacknowledged information transmission 

8.4.1 Transmission of unacknowledged information 

NOTE: The term "transmission of a UI frame" refers to the delivery of a UI frame by the LLC layer to the 
RLC/MAC or BSSGP layer. 

Unacknowledged information shall be passed from layer 3 to the LLC layer with the LL-UNITDATA-REQ (L3-PDU, 
Protect, Cipher) primitive. The L3-PDU shall be transmitted in a UI command frame to the peer LLE. The PM and 
E bits in the UI frame shall be set according to the Protect and Cipher parameters received from layer 3. 

8.4.2 Receipt of unacknowledged information 

On receipt of a UI command frame the contents of the information field shall be passed to the appropriate layer-3 entity 
with an LL-UNITDATA-IND (L3-PDU) primitive, except: 
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- if the DLCI of the recieved UI frame is not supported by the receiver; or 

- if N(U) of the received UI frame is in the range ( V(UR) - 32 ) < N(U) < V(UR) and if a UI frame with the same 
N(U) has already been received, 

then the UI frame shall be discarded without any further actions. 

V(UR) shall be set to N(U) + 1 unless N(U) is in the range ( V(UR) - 32 ) < N(U) < V(UR). 

8.5 Procedures for establishment and release of ABM operation 
8.5.1 Establishment of ABM operation 

8.5.1.1 General 

These procedures shall be used to establish ABM operation between the SGSN and an MS for a single SAPI. 

Layer 3 shall request establishment of ABM operation by use of the LL-ESTABLISH-REQ service primitive. Re- 
establishment may be initiated as a result of the LLC layer procedures defined in subclause 8.7. All frames other than U 
and UI frames received during the establishment procedures shall be ignored. 

8.5.1 .2 Establishment procedures 

An LLE shall initiate a request for the ABM operation to be set by transmitting the SABM command. All existing 
exception conditions shall be cleared, the retransmission counter shall be reset, and timer T200 shall be set. All mode- 
setting commands shall be transmitted with the P bit set to 1 . 

Layer 3-initiated establishment procedures imply the discard of all outstanding LL-DATA-REQ primitives and all 
I frames in queue. 

An LLE receiving a SABM command, if it is able to enter the ABM state, shall: 

inform layer 3 using the LL-ESTABLISH-IND primitive; 

- upon reception of an LL-ESTABLISH-RES primitive from layer 3 respond with an UA response with the F bit 
set to the same binary value as the P bit in the received SABM command (i.e., F=l); 

- set V(S), V(R), V(A), and B to 0; 

- enter the ABM state; 

clear all existing exception conditions; and 
clear any existing peer receiver busy condition. 
Upon reception of the UA response with the F bit set to 1, the originator of the SABM command shall: 

- reset timer T200; 

- set V(S), V(R), V(A), and B to 0; and 

enter the ABM state and inform layer 3 using the LL-ESTABLISH-CNF primitive. 
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Figure 16: ABM establishment procedure 

If the receiving LLE is unable to enter the ABM state, it shall respond to the SABM command with a DM response with 
the F bit set to the same binary value as the P bit in the received SABM command. ABM operation for SAPIs 1 and 7 is 
not permitted, and reception of a SABM command for these SAPIs shall be responded with a DM response. 

Upon reception of a DM response with the F bit set to 1, the originator of the SABM command shall indicate this to 
layer 3 by means of the LL-RELEASE-IND primitive, and reset timer T200. It shall then enter the ADM state. DM 
responses with the F bit set to shall be ignored in this case. 
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Figure 17: ABM establishment procedure, unsuccessful 

An LL-RELEASE-REQ primitive received during LLC layer initiated re-establishment shall be serviced on completion 
of the establishment operation. 

8.5.1 .3 Procedure on expiry of timer T200 

If timer T200 expires before the UA or DM response with the F bit set to 1 is received, the LLE shall: 

- retransmit the SABM command as defined above; 

set timer T200; and 

increment the retransmission counter. 

After retransmission of the SABM command N200 times, LLME shall indicate this to GMM by means of the LLGMM- 
STATUS-IND primitive, and the LLE shall send an LL-RELEASE-IND to layer 3 and enter ADM state. 

8.5.2 Termination of ABM operation 
8.5.2.1 General 

These procedures shall be used to terminate ABM operation between the SGSN and an MS. 

Layer 3 shall request termination of ABM operation by use of the LL-RELEASE-REQ service primitive. All frames 
other than U and UI frames received during the release procedures shall be ignored. 
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All outstanding LL-DATA-REQ primitives and all I frames in queue shall be discarded. 

If the Local parameter received in the LL-RELEASE-REQ primitive indicates local release, the LLE shall enter ADM 
state, reset timer T200, and notify layer 3 by means of the LL-RELEASE-CNF primitive. Otherwise, the procedures in 
subclauses 8.5.2.2 and 8.5.2.3 shall be followed. 

In the case of persistent lower layer deactivation the LLE shall discard all I queues and deliver to layer 3 an LL- 
RELEASE-CNF primitive if an LL-RELEASE-REQ primitive is outstanding, or otherwise an LL-RELEASE-IND 
primitive. 



8.5.2.2 



Release procedure 



An LLE shall initiate a request for release of the ABM operation by transmitting the DISC command with the P bit set to 
1 . Timer T200 shall then be set and the retransmission counter reset. 

An LLE receiving a DISC command while in ABM or Timer Recovery state shall transmit a UA response with the F bit 
set to the same binary value as the P bit in the received DISC command. An LL-RELEASE-IND primitive shall be 
passed to layer 3, and the ADM state shall be entered. 

If the originator of the DISC command receives either: 

a UA response with the F bit set to 1; or 

a DM response with the F bit set to 1, indicating that the peer LLE is already in ADM state; 

it shall enter the ADM state and reset timer T200. 

The LLE that issued the DISC command is now in the ADM state and shall notify layer 3 by means of the LL- 
RELEASE-CNF primitive. The conditions relating to this state are defined in subclause 8.5.4. 
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Figure 18: ABM release procedure 
8.5.2.3 Procedure on expiry of timer T200 

If timer T200 expires before a UA or DM response with the F bit set to 1 is received, the originator of the DISC 
command shall: 

- retransmit the DISC command as defined in subclause 8.5.2.2; 

set timer T200; and 

increment the retransmission counter. 

If the LLE has not received the correct response as defined in subclause 8.5.2.2 after N200 attempts to recover, then 
LLME shall indicate this to GMM by means of the LLGMM-STATUS-IND primitive, and the LLE shall enter the ADM 
state and notify layer 3 by means of the LL-RELEASE-CNF primitive. 

8.5.3 Automatic negotiation of LLC layer and layer-3 parameters 

Each LLE has an associated LLME that has the responsibility for initialising the LLC layer parameters necessary for 
correct peer-to-peer information transport. Initialisation of the parameters shall be done either according to the default 
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values, or according to the values supplied by the peer entity. The latter method utilises the parameter negotiation 
procedure. The negotiable parameters are listed in Table 6. 

The LLE shall issue an XID command containing the parameters that the LLE wants to negotiate, and set timer T200. 
The peer LLE shall, upon receipt of the XID command, return an XID response containing the list of parameter values 
that the peer can support. Timer T200 shall be reset when the XID response is received. XID frames shall be transmitted 
with the P/F bit set to 1. This is illustrated in Figure 19. 
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Figure 19: XID negotiation procedure 

XID frames can be used to negotiate layer-3 parameters. In this case, layer 3 sends the parameters to an LLE with the 
LL-XID-REQ primitive. The LLE shall issue an XID command containing the layer-3 parameters, and LLC layer 
parameters if any LLC layer parameters shall be negotiated. The peer LLE shall, upon receipt of the XID command, 
indicate the layer-3 parameters to layer 3 and upon receipt of an LL-XID-RES primitive return an XID response 
containing the list of parameter values that the peer can support. The layer-3 parameters received from the peer is sent to 
layer 3 with the LL-XID-CNF primitive. The LLE issuing the XID command shall set timer T200 when the XID 
command is transmitted, and reset timer T200 when the XID response is received. This is illustrated in Figure 20. 
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Figure 20: Layer 3 XID negotiation procedure 

8.5.3.1 Negotiation of parameter m 

The following rules shall apply when mD and mU are negotiated: 

If mD is negotiated to 0, then the LLEs shall not keep count of outstanding I frame octets in the downlink 
direction. If mU is negotiated to 0, then the LLEs shall not keep count of outstanding I frame octets in the uplink 
direction. 

If a S ABM or XID command with mD / is received in an LLE, and if the LLE does not want to apply the count 
of outstanding I frame octets in the downlink direction, then the LLE shall respond with mD = and with N201-I 
and kD so that N201-I multiplied with kD is less than or equal to the received MD. 

If a S ABM or XID command with mU ^ is received in an LLE, and if the LLE does not want to apply the count 
of outstanding I frame octets in the uplink direction, then the LLE shall respond with mU = and with N201-I 
and kU so that N201-I multiplied with kU is less than or equal to the received MU. 

mD and mU shall be negotiated to values that allow at least one I frame with information field length equal to the 
negotiated value of N201-I to be transmitted in each direction. 
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8.5.3.2 Unsuccessful XID negotiation 

In the case of a collision of XID commands, all XID commands shall be ignored. The MS shall restart the parameter 
negotiation on expiry of timer T200, while the SGSN shall do so on expiry of twice the value of timer T200. An 
unsuccessful XID exchange shall be repeated on expiry of timer T200. 

If a SABM or XID command with an invalid XID information field is received, then the SABM or XID command, 
respectively, shall be ignored. 

If a UA or XID response with an invalid XID information field is received, then the UA or XID response shall be 
ignored, the SABM or XID command shall be retransmitted, and the retransmission counter shall be incremented. 

An XID information field shall be treated as invalid if it: 

contains an XID parameter field that violates the LLC frame format (see Figure 3); 

contains the IOV-UI or IOV-I parameter in the uplink direction; or 

in the UA or XID response case, contains a value that violates the sense of negotiation or that is out of range (see 
Table 6). 

If an XID parameter with an unrecognised Type field is received, then this parameter shall be disregarded and not 
responded to. If the received XID information field is valid, and if one or more XID parameters with recognised type but 
with unsupported lengths or out-of -range values are detected, then these parameters shall be responded to with lengths 
and values set according to the responder's preferences. 

8.5.3.3 Procedure on expiry of timer T200 

If timer T200 expires before the XID response with the F bit set to 1 is received, the LLE shall: 

- retransmit the XID command; 

set timer T200; and 

increment the retransmission counter. 

After retransmission of the XID command N200 times, LLME shall indicate this to GMM by means of the LLGMM- 
STATUS-IND primitive, and the LLE shall send an LL-RELEASE-IND to layer 3, and enter ADM state if not already 
in ADM state. 

8.5.4 TLLI Assigned / ADM state 

While in the TLLI Assigned / ADM state: 

the receipt of a DISC command shall result in the transmission of a DM response with the F bit set to the value of 
the received P bit; 

on receipt of a SABM command, the procedures defined in subclause 8.5.1 shall be followed; 

on receipt of an unsolicited DM response with the F bit set to 0, the LLE shall, if it is able to, initiate the 
establishment procedures by the transmission of a SABM (see subclause 8.5.1.2), otherwise, the DM shall be 
ignored; 

on receipt of UI commands, the procedures defined in subclause 8.4 shall be followed; 

on receipt of XID commands, the procedures defined in subclause 8.5.3 shall be followed; 

on receipt of any unsolicited UA response an LLGMM-STATUS-IND primitive indicating a possible multiple- 
assignment of a TLLI value shall be issued; 

the receipt of an S or I+S command frame shall result in the transmission of a DM response with the F bit set to 
0;and 

all other frame types shall be discarded. 
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8.5.5 Collision of unnumbered commands and responses 

8.5.5.1 Identical transmitted and received commands 

If the transmitted and received unnumbered commands (S ABM without an information field, or DISC) are the same, the 
LLEs shall send the UA response at the earliest possible opportunity. The indicated state shall be entered after receiving 
the UA response. The LLE shall notify layer 3 by means of the appropriate confirm primitive. 

If the transmitted and received unnumbered commands are S ABM commands and only one of the commands contain an 
information field, the LLEs shall send the UA response at the earliest possible opportunity. ABM shall be entered after 
receiving the UA response, and the negotiated XID values shall take effect. 

If the transmitted and received unnumbered commands are S ABM commands with an information field, the LLEs shall 
not send the UA response. The S ABM commands shall instead be repeated with the same mechanism as defined for XID 
collision in subclause 8.5.3.2. 

8.5.5.2 Different transmitted and received commands 

If the transmitted and received unnumbered commands are a S ABM and a DISC command, the LLEs shall issue a DM 
response at the earliest possible opportunity. Upon receipt of a DM response with the F bit set to 1, the LLE shall enter 
the ADM state and notify layer 3 by means of the appropriate primitive. The LLE receiving the DISC command shall 
issue an LL-RELEASE-IND primitive, while the other LLE shall issue an LL-RELEASE-CNF primitive. 

If the transmitted unnumbered command is a S ABM command with an information field, and the received unnumbered 
command is an XID command, then the LLE shall ignore the received XID command. 

If the transmitted unnumbered command is an XID command, and the received unnumbered command is a S ABM 
command with an information field, then the LLE shall send the UA response at the earliest possible opportunity if it is 
able to enter ABM. The transmitted XID command shall be treated as not transmitted. 

8.5.6 Unsolicited DM response and SABM or DISC command 

When a DM response with the F bit set to is received by an LLE, a collision between a transmitted SABM or DISC 
command and the unsolicited DM response may have occurred. 

In order to avoid misinterpretation of the DM response received, an LLE shall always send its SABM or DISC 
command with the P bit set to 1 . 

A DM response with the F bit set to colliding with a SABM or DISC command shall be ignored. 

8.6 Procedures for information transfer in ABM operation 

Having either transmitted the UA response to a received SABM command or received the UA response to a transmitted 
SABM, I frames and supervisory frames may be transmitted and received. The procedures that apply to the transmission 
of I frames are defined below. 

NOTE: The term "transmission of an I frame" refers to the delivery of an I frame by the LLC layer to the 
RLC/MAC or BSSGP layer. 

Each LLE shall store the history of the transmitted I frames, i.e., the LLE shall remember the I-frame transmission 
sequence. The history is used to decide which I frames to retransmit. Due to retransmission, the history is not necessarily 
an in-order sequence. 

A frame within the receive window is either: 

- received: the frame has been correctly received; or 

not received: the frame has not been correctly received. 

A frame within the transmit window is either: 
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not yet transmitted: the frame has not yet been transmitted; 

transmitted: the frame has been (re-)transmitted, but the LLE does not know if the frame has been received in the 
peer LLE; 

acknowledged: the frame has been acknowledged by the peer LLE; or 

marked for retransmission: the LLE has decided to retransmit this I frame. 

I frames shall be transmitted in ascending N(S) order. When I frames are retransmitted, the frame with the lowest N(S) 
shall be retransmitted first. This is used by the receiving LLE to detect lost frames as described in subclause 8.6.3.1. 

8.6.1 Transmitting I frames 

Information received by the LLE from layer 3 by means of an LL-DATA-REQ primitive shall be transmitted in an 
I frame, provided that the LLE is not in the peer receiver busy condition. The control field parameters N(S) and N(R) 
shall be assigned the values V(S) and V(R), respectively. V(S) shall be incremented by 1 at the end of the transmission 
of the I frame. 

The I frame buffer variable B shall be incremented with the length of the information field of I frame number N(S), so 
that B = B + L(N(S)). The value of B shall never exceed M. If L(N(S)) > M - B (where M is the maximum buffer size - 
see subclause 8.9.6), then the LLE shall not transmit any new I frames, but may retransmit I frames as a result of the 
error recovery procedures as described in subclauses 8.6.3 and 8.6.6. 

When there is an opportunity to transmit a frame, then the LLE shall do one of the following in order of priority: 

If there are any I frames marked for retransmission and if the LLE is not in the peer receive busy condition, then 
the LLE shall increment by 1 the retransmission count variable for the I frame with the lowest send sequence 
number N(S). If the retransmission count variable exceeds the value of N200, then the LLE shall initiate the re- 
establishment procedure as described in subclause 8.7.2. If the retransmission count variable does not exceed the 
value of N200, then the LLE shall retransmit the I frame. 

If the LLE has a new I frame to transmit, if V(S) < V(A) + k (where k is the maximum number of outstanding 
I frames - see subclause 8.9.7), and if the LLE is not in the peer receiver busy condition, then the new I frame 
shall be transmitted. 

If the LLE has an acknowledgement to transmit (see subclause 8.6.3. 1), then the LLE shall transmit an S frame. 

If the LLE wants to request an acknowledgement (see subclause 8.6.3.3), then the A bit of the transmitted frame shall be 
set to 1 . 

When the SGSN or MS is in the own receiver busy condition, it may still transmit I frames, provided that a peer receiver 
busy condition does not exist. 
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Figure 21 : Transmitting and receiving I frames 
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8.6.2 Receiving I frames 



When an LLE is not in the own receiver busy condition and receives a valid I frame whose N(S) is equal to the current 
V(R), the LLE shall: 

- pass the information field of this frame to layer 3 using the LL-DATA-IND primitive; 

increment by 1 its V(R); and 

if the A bit of the received I frame was set to 1, then the LLE shall respond to its peer with an RR, RNR, SACK, 
or ACK frame (see subclause 8.6.4.1). 

When an LLE receives a valid I frame whose N(S) is not in the range V(R) < N(S) < V(R) + k, the LLE shall discard the 
frame as a duplicate. 

When an LLE is not in the own receiver busy condition and receives a valid I frame where V(R) < N(S) < V(R) + k, 
then the LLE shall store the I frame until all frames from V(R) to N(S) - 1 inclusive are correctly received. The LLE 
shall use the control field information of the received I frame before storing the frame. The LLE shall then: 

- pass the information field of this I frame to layer 3 using the LL-DATA-IND primitive; and 

- set its V(R) = N(S)+ 1. 

When an LLE receives a valid I frame and the LLE is in the own receiver busy condition, then the acceptance of the 
I frame is implementation dependent. 

8.6.3 Sending and receiving acknowledgements 

NOTE: Sending and receiving acknowledgements refer to the transmission and reception of frames carrying ABM 
acknowledgement information, i.e., I+S and S frames. 

8.6.3.1 Sending acknowledgements 

Whenever an LLE receives a frame with the A bit set to 1, it shall transmit an I+S or S frame. Whenever an LLE detects 
an error in the sequence of received I frames, it shall transmit an I+S or S frame. The supervisory function bits of the 
transmitted frame shall be set according to subclause 8.6.4.1. 

The receiving LLE shall use the knowledge of the (re-)transmission strategy of its peer LLE (see subclause 8.6. 1) to 
detect sequence errors. If the LLE receives an I frame with a higher N(S) than the N(S) of the previously received 
I frame, and if there are I frames missing between these two N(S) values, then the LLE shall assume that the missing 
I frames have been lost. If the LLE receives an I frame with a lower N(S) than the N(S) of the previously received 
I frame, it can assume that its peer LLE has (re-)started retransmission due to the reception of an acknowledgement. 

8.6.3.2 Receiving acknowledgements 

On receipt of a valid I+S or S frame , the LLE shall, if N(R) is valid, treat the N(R) contained in this frame as an 
acknowledgement for all the I frames it has transmitted with an N(S) up to and including the received N(R) - 1 . A valid 
N(R) value is one that is in the range V(A) < N(R) < V(S). If N(R) is not valid, and if the received frame is an S frame, 
then the frame shall be discarded without further action. If N(R) is not valid, and if the received frame is an I+S frame, 
then N(R), the A bit, and the SACK bitmap, if received, shall be disregarded. 

For each I frame transmitted with N(S) in the range V(A) < N(S) < N(R), the frame length L(N(S)) shall be subtracted 
from the I frame buffer variable B, so that B = B - L(N(S)). The value of B shall never be less than 0. V(A) shall then be 
set to N(R). 

On receipt of a valid ACK frame, the LLE shall consider the I frame transmitted with sequence number N(R) + 1 as 
acknowledged. 

On receipt of a valid SACK frame, the LLE shall consider all I frames with the corresponding bit set to 1 in the SACK 
bitmap as acknowledged. 

If timer T200 is running and associated with an acknowledged I frame, then timer T200 shall be reset. 
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The LLE shall determine which I frames to retransmit by analysing its I frame transmission sequence history and the 
acknowledgements received. An unacknowledged I frame that was transmitted prior to an acknowledged I frame shall be 
considered lost and shall be marked for retransmission. Acknowledged I frames shall be removed from the I frame 
transmission sequence history. 

8.6.3.3 Requesting acknowledgements 

The LLE shall request an acknowledgement from the peer LLE by transmitting an I+S or S frame with the A bit set to 1 . 
The LLE may request an acknowledgement at any time. An acknowledgement shall be requested when: 

- the last I frame in a sequence of one or more I frames is transmitted; or 

V(S) = V(A) + k as a result of the transmission of the I frame. 

When requesting an acknowledgement, the LLE shall set timer T200 and associate the timer with the I frame currently 
being transmitted, or, if the A bit is transmitted in an S frame, with the I frame last transmitted. 

8.6.4 Peer receiver busy condition 

After receiving a valid RNR frame, the LLE shall: 

set a peer receiver busy condition; 

not transmit nor retransmit any I frames to the peer LLE; 

treat the N(R) contained in the received RNR frame as an acknowledgement for all the I frames that have been 
(re-)transmitted with an N(S) up to and including N(R) - 1, and set its V(A) to the value of the N(R) contained in 
the RNR frame; 

set timer T200 to initiate the inquiry process; and 

- reset the retransmission count variable. 
If timer T200 expires, the LLE shall: 

add one to its retransmission count variable; 

if the value of the retransmission count variable is less than N200: 

transmit an appropriate supervisory frame (see subclause 8.6.4.1) with a A bit set to 1; and 

set timer T200; 

if the value of the retransmission count variable is equal to N200, initiate a re-establishment procedure as defined 
in subclause 8.7. LLME shall indicate this by means of the LLGMM-STATUS-IND primitive to GMM. 

The LLE receiving the supervisory frame with the A bit set to 1 shall respond, at the earliest opportunity, with an 
appropriate supervisory frame (see subclause 8.6.4.1) to indicate whether or not its own receiver busy condition still 
exists. 

Upon receipt of the supervisory frame, the LLE shall reset timer T200, and: 

- if the frame is an RR, ACK or SACK frame: 

the peer receiver busy condition shall be cleared; and 

the LLE may transmit new I frames or retransmit I frames as defined in subclauses 8.6.1 or 8.6.3, 
respectively; or 

if the frame is an RNR frame, then the LLE shall proceed according to subclause 8.6.4, first paragraph. 

Upon receipt of a SABM command, the LLE shall clear the peer receiver busy condition. 
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8.6.4.1 Supervisory frame selection 

If the LLE is in the own receiver busy condition, the appropriate supervisory frame is the RNR frame. 

Otherwise, if the highest-numbered I frame was received with N(S) = V(R), the appropriate supervisory frame is the RR 
frame. 

Otherwise, if the highest-numbered I frame was received with N(S) = V(R) + 1, the appropriate supervisory frame is the 
ACK frame. 

Otherwise, the appropriate supervisory frame is the SACK frame. 

8.6.5 Own receiver busy condition 

When the LLE enters the own receiver busy condition, it shall transmit an RNR frame at the earliest opportunity. 

All received I frames may be discarded, after updating V(A). If the A bit of a received I frame was set to 1, then the LLE 
shall transmit an RNR frame. 

All received supervisory frames shall be processed, including updating V(A). If the A bit of a received S frame was set 
to 1, then the LLE shall transmit an RNR frame. 

To indicate to the peer LLE the clearance of the own receiver busy condition, the LLE shall transmit an appropriate 
supervisory frame (see subclause 8.6.4.1). 

The transmission of a SABM command or a UA response (in reply to a SABM command) also indicates to the peer LLE 
the clearance of the own receiver busy condition. 



8.6.6 Waiting for acknowledgement 



Frames may be lost any time during transmission due to e.g., transmission errors. An LLE that has not received 
acknowledgement for a transmitted I frame shall therefore on the expiry of timer T200 take appropriate recovery action. 

The LLE shall maintain an internal retransmission count variable for each transmitted I frame. 

If timer T200 expires, the LLE shall increment by 1 the retransmission count variable for the I frame associated with 
timer T200, and: 

if the value of the retransmission count variable does not exceed N200, set timer T200, and retransmit the I frame 
with the A bit set to 1 ; or 

if the value of the retransmission count variable exceeds N200, initiate a re-establishment procedure as defined in 
subclause 8.7.2. LLME shall indicate this by means of the LLGMM-STATUS-IND primitive to GMM. 

8.7 Re-establishment of ABM operation 
8.7.1 Criteria for re-establishment 

The criteria for re-establishing the ABM mode of operation are defined in this clause by the following conditions: 
- the receipt, while in the ABM state, of a SABM; 

the receipt of an LL-ESTABLISH-REQ primitive from layer 3 (see subclause 8.5.1.1); 

the occurrence of N200 retransmission failures (see subclauses 8.6.4 and 8.6.6); 

the occurrence of a frame rejection condition as identified in subclause 8.8.2; 

the receipt, while in the multiple-frame mode of operation, of a FRMR response frame (see subclause 8.8.3); and 

the receipt, while in the multiple-frame mode of operation, of an unsolicited DM response with the F bit set to 

(see subclause 8.8.4). 
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8.7.2 Procedures 

In all re-establishment situations, the LLE shall follow the procedures defined in subclause 8.5.1. All locally-generated 
conditions for re-establishment shall cause the transmission of the S ABM. 

In the case of LLC layer and peer-initiated re-establishment, the LLE shall, if V(S) > V(A) prior to re-establishment, 
issue an LL-ESTABLISH-IND primitive to layer 3, and discard all I queues, and LLME shall issue an LLGMM- 
STATUS-IND primitive to GMM. 

In case of layer 3-initiated re-establishment, or if an LL-ESTABLISH-REQ primitive occurs pending re-establishment, 
the LL-ESTABLISH-CNF primitive shall be used. 

8.8 Exception condition reporting and recovery 

Exception conditions may occur as the result of lower layer errors or LLC layer procedural errors. 

The error recovery procedures available to effect recovery following the detection of an exception condition at the LLC 
layer are defined in this subclause. 

8.8.1 Invalid frame condition 

Any received invalid frame shall be discarded, and no action shall be taken as a result of that frame. 

8.8.2 Frame rejection condition 

A frame rejection condition results from one of the conditions described in subclause 6.4.1.5 items 1) to 3). 

Upon occurrence of a frame rejection condition whilst in ABM operation, the LLME shall issue an LLGMM-STATUS- 
IND primitive; and the LLE shall initiate re-establishment (see subclause 8.7.2). 

Upon occurrence of a frame rejection condition during establishment of or release from ABM operation, or whilst in 
ADM state, the LLE shall discard the frame. 

8.8.3 Receipt of a FRMR response frame 

Upon receipt of a FRMR response frame whilst in ABM operation, the LLME shall issue an LLGMM-STATUS-IND 
primitive; and the LLE shall initiate re-establishment (see subclause 8.7.2). 

8.8.4 Unsolicited response frames 

The action to be taken on the receipt of an unsolicited response frame is defined in Table 8. Upon the receipt of an 
unsolicited UA response, the LLE shall assume a possible multiple-TLLI assignment, and LLME shall inform GMM. 

Table 8: Actions taken on receipt of unsolicited response frames 



Unsolicited 

Response 

Frame 


State 


TLLI Assigned 
/ADM 


Local 
Establishment 


Local 
Release 


ABM 


Timer 
Recovery 


UA response 
F=1 


LLGMM- 
STATUS-IND 


Solicited 


Solicited 


LLGMM-STATUS-IND 


LLGMM-STATUS-IND 


UA response 
F = 


LLGMM- 
STATUS-IND 


LLGMM- 
STATUS-IND 


LLGMM- 
STATUS-IND 


LLGMM-STATUS-IND 


LLGMM-STATUS-IND 


DM response 
F = 1 


Ignore 


Solicited 


Solicited 


LLGMM-STATUS-IND 


LLGMM-STATUS-IND 
Re-establish ABM 


DM response 
F = 


Establish ABM 


Ignore 


Ignore 


LLGMM-STATUS-IND 
Re-establish ABM 


LLGMM-STATUS-IND 
Re-establish ABM 


Supervisory 
response 


Ignore 


Ignore 


Ignore 


Solicited 


Solicited 
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8.8.5 Multiple assignment of TLLI value 

An LLE shall assume multiple assignment of a TLLI value and initiate recovery upon: 

the receipt of a UA response frame whilst in ABM state;; and 

the receipt of a UA response frame whilst in the TLLI Assigned ADM state. 
LLME shall then inform GMM by means of the LLGMM-STATUS-IND primitive. 



8.9 List of LLC layer parameters 



The LLC layer parameters listed in this subclause are associated with each DLCI, except the LLC version number and 
IOV-UI that are associated with a TLLI. 

A method of assigning these parameters is defined in subclauses 6.4.1.6 and 8.5.3. 

Table 9 provides an overview of the LLC layer parameters and summarises the recommended default values to be used 
in GSM networks. The term default implies that the value defined should be used in the absence of any assignment or 
negotiation of alternative values. 

Some of the parameters, e.g., T200 and N200, may have the same name as parameters used in other GSM specifications. 
All the parameters listed here are local to the LLC layer protocol, and shall not impact or be impacted by parameters 
with the same name in other specifications. 

8.9.1 LLC version number (Version) 

The LLC version number (Version) is an LLC layer parameter. The default version number is given in Table 9. 

8.9.2 Input Offset Value (IOV) 

The Input Offset Value (IOV) is an LLC layer parameter used for ciphering. IOV is a random 32 bit value, generated by 
the SGSN. See also annex A. The default value of IOV is given in Table 9. 

The value for IOV can be different for I frames and UI frames. IOV-UI is IOV for UI frames. IOV-I is IOV for I frames. 

8.9.3 Retransmission timer (T200) 

The retransmission timer (T200) is an LLC layer parameter. Upon expiry of timer T200, retransmission of a frame may 
be initiated according to the procedures described in clause 8. The default value of timer T200 for each SAPI is given in 
Table 9. 

8.9.4 Maximum number of retransmissions (N200) 

The maximum number of retransmissions of a frame (N200) is an LLC layer parameter. The default value of N200 for 
each SAPI is given in Table 9. 

8.9.5 Maximum number of octets in an information field (N201 ) 

The maximum number of octets in an information field (N201) is an LLC layer parameter. See also subclause 5.4. The 
default value of N201 for each SAPI is given in Table 9. The minimum value of N201 shall be 140 octets, and the 
maximum value shall be 1 520 octets. 

The value of N201 may be different for I frames and U and UI frames. N201-I is used for I frames and N201-U is used 
for U and UI frames. 
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8.9.6 Maximum I frame buffer size (m) 

The maximum I frame buffer size (m) that may be used to buffer outstanding I frame information fields at any given 
time is an LLC layer parameter that shall not exceed 24 320 in units of 16 octets. The default values of m are given in 
Table 9. If the value of m equals 0, then the LLE shall not keep count of the number of outstanding I frame octets, i.e., 
the I frame buffer variable B shall not be used. M is the maximum buffer size expressed in octets, so that M = m • 16. 

The value of m can be different in each direction of transmission. mD is m in the downlink direction. mU is m in the 
uplink direction. 

8.9.7 Maximum number of outstanding I frames (k) 

The maximum number (k) of sequentially-numbered I frames that may be outstanding (i.e., unacknowledged) at any 
given time is an LLC layer parameter that shall not exceed 256. k is also denoted window size. The default values of k 
are given in Table 9. 

The value of k can be different in each direction of transmission. kD is k in the downlink direction, and kU is k in the 
uplink direction. 

Table 9: LLC layer parameter default values 



LLC 
Parameter 


SAPI1 
GMM 


SAPI 3 
User Data 1 


SAPI 5 
User Data 2 


SAPI 7 
SMS 


SAPI 9 
User Data 3 


SAPI 1 1 
User Data 4 


Version 





IOV-UI 





IOV-1 





T200 


5s 


5s 


10s 


20 s 


20 s 


40 s 


N200 


3 


3 


3 


3 


3 


3 


N201-U 


270 


500 


500 


270 


500 


500 


N201-I 


Note 2 


1 520 


1 520 


Note 2 


1 520 


1 520 


mD 


Note 2 


1 520 


760 


Note 2 


380 


190 


mU 


Note 2 


1 520 


760 


Note 2 


380 


190 


kD 


Note 2 


16 


8 


Note 2 


4 


2 


kU 


Note 2 


16 


8 


Note 2 


4 


2 


NOTE 1 : The proper operation of the procedure requires that timer T200 be greater than the maximum time between 

transmission of command frames and the reception of their corresponding response or acknowledgement 

frames. 
NOTE 2: This parameter applies to ABM procedures. ABM operation is not allowed for GMM and SMS that use only 

Ul frames for information transfer. 
NOTE 3: The default values for SAPIs 3, 5, 9, and 1 1 have been chosen to correspond with the four GPRS quality of 

service delay classes, see GSM 02.60. However, there is no fixed relationship between SAPI and delay class. 

The LLC layer parameters for any SAPI can be negotiated to support any QoS profile, see GSM 03.60. 
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Annex A (normative): 
Ciphering 

A.1 General 

This annex specifies how LLC shall interface with the GPRS ciphering algorithm. The requirements for the GPRS 
ciphering algorithm are contained in GSM 01.61. 

A.2 Ciphering algorithm interface 

The ciphering algorithm has three input parameters: 

the ciphering key (Kc); 

the frame-dependent input (Input); and 

the transfer direction (Direction). 
The ciphering algorithm has one output parameter: 

- Output. 
The relationship between the input and output parameters and the ciphering algorithm is illustrated in Figure A.l. 



Kc 



Input Direction 

J L 



Unciphered 
Frame 



Ciphering 
Algorithm 



Output 




Kc 



Ciphered Frame 



Input Direction 

J L 



Ciphering 
Algorithm 



Output 




Deciphered 

Frame 



MS or SGSN SGSN or MS 

Figure A.1 : GPRS ciphering environment 

The input and output parameters and the other elements from Figure A.l are defined in Table A.l. 
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Table A.1 : Ciphering parameters and frames 



Parameter 


Length 


Description 


Kc 


64 bits 


The LLGMM-ASSIGN-REQ Kc parameter received from GMM. 


Input 


32 bits 


A modulo counter as defined in subclause A. 2.1 . 


Direction 


1 bit 


Set to if the direction of LLC frame transmission is from the MS to the SGSN. 
Set to 1 if the direction of LLC frame transmission is from the SGSN to the MS. 


Ciphering 
Algorithm 


- 


A GPRS ciphering algorithm as determined by the LLGMM-ASSIGN-REQ 
Ciphering Algorithm parameter received from GMM. 


Output 


maximum 
1 523 octets 


The output of Ciphering Algorithm. 


Unciphered 
Frame 


maximum 
1 523 octets 


An LLC layer I or Ul frame to be ciphered. 


Ciphered 
Frame 


maximum 
1 523 octets 


A ciphered LLC layer I or Ul frame. Only the information field and the FCS field 
shall be ciphered. Ciphered Frame shall be generated by bitwise XOR of Output 
and the Information Field and FCS Field of Unciphered Frame. 


Deciphered 
Frame 


maximum 
1 523 octets 


A deciphered LLC layer I or Ul frame. Deciphered Frame shall be generated by 
bitwise XOR of Output and the ciphered part of Ciphered Frame. When transmitting 
an LLC frame, Deciphered Frame shall be identical to Unciphered Frame if no 
transmission errors have occurred. 



It is an implementation option to optimise the ciphering algorithm by for example producing only as many Output octets 
as is needed to cipher Unciphered Frame. 



A.2.1 Generation of Input 



The Input parameter shall be generated according to the following algorithm if the frame is a Ul frame: 

Input = ( ( IOV-UI ® SX )+ LFN + OC ) modulo 2 32 
The Input parameter shall be generated according to the following algorithm if the frame is an I frame: 

Input = ( IOV-I + LFN + OC ) modulo 2 32 
where: 

IOV-UI is a 32 bit random value generated by the SGSN. 

IOV-I is a 32 bit random value generated by the SGSN. 

LFN is the LLC frame number in the LLC frame header. LFN is a binary value with a length of nine bits. For 
I frames, N(S) shall be used as the LFN. For Ul frames, N(U) shall be used as the LFN. 

OC is a binary overflow counter that is calculated and maintained independently at the sending and receiving 
sides. The length of OC is 32 bits. There are four OC counters associated with each DLCI; two for 
unacknowledged information transfer (one for each direction of transmission), and two for acknowledged 
information transfer (one for each direction of transmission). All OCs for unacknowledged information transfer 
shall be set to zero whenever a new IOV-UI value is negotiated. The OCs for acknowledged operation shall be 
set to zero whenever ABM operation is (re-)established. OC shall be incremented by 512 every time when the 
corresponding LFN rolls over, i.e., when LFN exhausts its modulo and restarts counting from zero, so that OC 
and LFN when added together in effect is a 32 bit modulo 2 32 counter. 

SX is a 32 bit SAPI XOR mask. The 28 least significant bits shall be set to zero. The four most-significant bits 
shall be set according to the SAPI of the LLC frame. 

+ is the binary addition operation. 

® is the bitwise XOR operation. 
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Annex B (informative): 

LLC layer states for peer-to-peer operation 



B.1 General 



The purpose of this annex is to provide a representative example of the peer-to-peer procedures of the LLC layer, to 
assist in the understanding of this specification. This representation does not describe all of the possible actions of the 
LLC layer. The representation does therefore not constrain implementations from exploiting the full scope of the 
procedures as presented within the text of this specification. The text description of the procedures is normative. 

The representation is a model of the peer-to-peer procedures of the LLC layer and is applicable to the LLC layers at 
both the MS and SGSN sides for all ranges of TLLI values. 



Service user 
(MS side) 



Service user 
(network side) 



LLC layer 



< 



Management 
procedures 



> 



< 



Point-to-point 
procedures 



PTP connection 



> 



Point-to-point 
procedures 



Management 
procedures 



Figure B.1 : Model of the LLC layer peer-to-peer procedures 



B.2 An overview of the peer-to-peer LLC layer states 

The state diagram representation of the peer-to-peer procedures is based on an expansion of the three basic states 
identified in subclause 4.5.2 to 7 states. An overview of the inter-relationship of these states is provided in Figure B.2. 

An LLME and its LLEs are conceptually initiated in the TLLI Unassigned state (state 1). LLME interacts with GMM in 
order to be assigned a TLLI value. TLLI assignment causes LLME to transition to the TLLI Assigned state (state 2) and 
each of its LLEs to transition to the ADM state (state 2). 

The receipt of an LL-ESTABLISH-REQ primitive by an LLE in the ADM state (state 2) causes the initiation of the local 
establishment procedure and the transition to the Local Establishment state (state 3). Completion of the establishment 
procedure takes the LLE to the ABM state (state 5). 

Peer-initiated establishment causes a transition from the ADM state (state 2) to the Remote Establishment state (state 4). 
The receipt of an LL-ESTABLISH-RES primitive completes the establishment procedure and moves the LLE to the 
ABM state (state 5). In ABM state (state 5), LL-DATA-REQ primitives can be serviced directly subject to the 
restrictions of the procedures. 

Expiry of timer T200, that is used in both the flow control and data transfer aspects of each LLE's procedures initiates 
the transition to the Timer Recovery state (state 7). Completion of the timer recovery procedures returns the LLE to the 
ABM state (state 5). In states 5 and 7, the following conditions that are identified within the LLC specification are 
observed: 

- peer receiver busy;; and 

own receiver busy. 

A peer-initiated release takes the LLE directly to the ADM state (state 2), whilst an LL-RELEASE-REQ returns the LLE 
state to the ADM state via the Local Release state (state 6). 

TLLI Unassignment causes a transition to the TLLI Unassigned state (state 1) from any other state (states 2-7). 
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In addition, all states should observe the suspended operation (reception of LLGMM-SUSPEND-REQ) restrictions, 
during which LLC frames may not be transmitted. 



Any State 



TLLI 
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Figure B.2: Overview of the states of the peer-to-peer procedures 
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Annex C (informative): 
Document history 





5.0.0 


October 1997 


SMG#23 approved. 


5.1.0 


December 1997 


Included SMG#24 approved change requests A001 through A014. 


5.2.0 


March 1998 


Included SMG#25 approved change requests A015 and A017 through A021. 


6.0.0 


March 1998 


New version number as decided by SMG#25. 


6.1.0 


June 1998 


Included SMG#26 approved change requests A016 and A023 through A030. 
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